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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

The content of this specification is a part of overall solution to meet the requirement of the interworking between EPS 
and the legacy system, mainly for the interfaces between S4-SGSN/MME and HSS/HLR/EIR. 
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Scope 



The present document is to specify the InterWorking Function (IWF) between MAP-based Gr, Gf interfaces and 
Diameter-based S6a, S6d, S13, SI 3a interfaces. 

For each IWF scenario, the present document will specify the mapping of related procedures and the corresponding 
parameter handling. 

The present document will also specify the related mechanisms for the IWF, e.g. message routing, user data handling 
The other mechanism, such as security, will also be described in this document as a part of the whole solution. 

If there is no specific indication, the SGSN in the specification refers to a S4-SGSN which supports S4 interface. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 33.401 : "3GPP System Architecture Evolution: Security Architecture". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

example: text used to clarify abstract rules by applying them literally. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 
<symbol> <Explanation> 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

EPS Evolved Packet System 

IWF Interworking Function 

TAU Tracking Area Update 
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4 Introduction (Informative) 

4.1 General Description 

The interworking scenarios in this specification are described based on interface mapping. 
The stage 2 network deployments for each of the interworking scenarios are also described. 

4.2 Scenario One: S6a/S6d - Pre Rel8 Gr interworking scenario 
with one IWF 

4.2.1 General Description 

This interworking scenario is for S6a/S6d interface based on Diameter and Pre Rel8 Gr interface based on MAP with 
one IWF in the path. 

This IWF scenario can be an inter PLMN use case. 

This IWF scenario can be an intra PLMN use case for operator to do the partly update of their legacy network. 

This interworking scenario is described as below: 

VPLMN (EPS) HPLMN (Pre-REL8) 











Pre-REL8 
HLR 


MME/SGSN 


IWF 


S6a/S6d 


Pre Rel8 Gr 











Figure 4.2.1-1 S6a/S6d - Pre Rel8 Gr interworking scenario witli one IWF 

The Pre Rel8 HLR shall be upgraded to support Rel-8 EPS security and Pre Rel8 Gr shall be upgraded to support 
transfer of Rel-8 security parameters.. 

4.2.2 Network Deployments 

This IWF scenario will apply the following network deployment situation: 

- Users of a Pre Rel8 UMTS/GPRS network access into a visited EPS with only E-UTRAN, which is described as 
below: 
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UE 



Figure 4.2.2-1 IWF Scenario one network deployment: visited EPS with E-UTRAN only, home Pre Rel8 

UMTS/GPRS only 

The subscription data for Pre Rel8 Gn/Gp SGSN is downloaded to MME. Mapping of the subscription data is done on 
MME. Additional security solution is needed in which the Pre Rel8 HLR can not be changed. 

- Users of a Pre Rel8 UMTS/GPRS network access into a visited EPS with E-UTRAN and UTRAN/GERAN, 
which is described as below: 




UE 



Figure 4.2.2-2 IWF Scenario one network deployment: visited EPS with E-UTRAN and 
UTRAN/GERAN, home Pre Rel8 UMTS/GPRS only 
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The subscription data for Pre Rel8 Gn/Gp SGSN is downloaded toSGSN. Mapping of the subscription data is done on 
SGSN. Security solution is not needed because the security mechanism in visited and home network is the same. 

4.3 Scenario Two: S6a/S6d - Rel8 Gr interworking scenario 
with one IWF 

4.3.1 General Description 

This interworking scenario is for S6a/S6d interface based on Diameter and Rel8 Gr interface based on MAP with one 
IWF in the path. 

This IWF scenario can be an inter PLMN use case. 

This IWF scenario can be an intra PLMN use case for operator to do the partly update of their legacy network. 

This interworking scenario is described as below: 



VPLMN (EPS) 



HPLMN (UMTS/GPRS/EPS) 



MME/SGSN 




IWF 




Rel8 HLR 







S6a/S6d 



Rel8 Gr 



Figure 4.3.1-1 S6a/S6d - Rel8 Gr interworking scenario witli one IWF 

4.3.2 Network Deployments 

This IWF scenario will apply the following network deployment situation: 

Users of a Rel8 UMTS/GPRS network access into a visited EPS with only E-UTRAN, which is described as 
below: 
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UE 



Figure 4.3.2-1 IWF Scenario two network deployment: visited EPS with E-UTRAN only, home Rel8 

UMTS/GPRS only 

The subscription data for Rel8 Gn/Gp SGSN is downloaded to MME. Mapping of the subscription data is done on 
MME. Additional security solution is needed in which the Pre Rel8 HLR can be changed. 



Users of a Rel8 UMTS/GPRS network access into a visited EPS with E-UTRAN and UTRAN/GERAN, which 
is described as below: 




Figure 4.3.2-2 IWF Scenario two network deployment: visited EPS with E-UTRAN and UTRAN/GERAN, 

home Rel8 UMTS/GPRS only 
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The subscription data for Rel8 Gn/Gp SGSN is downloaded to SGSN. Mapping of the subscription data is done on 
SGSN. Security solution is not needed because the security mechanism in visited and home network is the same. 

- Users of a Pre Rel8 UMTS/GPRS/E-UTRAN network access into a visited EPS with E-UTRAN and 
UTRAN/GERAN, which is described as below: 



Rel8 Gr 




^^>^-^ 




-^.^^^^ 


^ 


Rel8 
HSS 


/ 


\ 








/ 


MME 

/"-v" 


^ 


-^^ 


Gn/Gp 
ksGSJi, 





Pre Rel8 
UTRAN, 



Pre Rel8 
GERAN; 



UE 



Figure 4.3.2-3 IWF Scenario two networl< depioyment: visited EPS witli E-UTRAN and UTRAN/GERAN, 
liome EPS witli E-UTRAN only and Pre Rel8 UMTS/GPRS 

The subscription data for Pre Rel8 Gn/Gp SGSN and the subscription data for MME is downloaded to SGSN. Mapping 
of the subscription data is done on SGSN. Security solution is not needed because the security mechanism in visited and 
home network is the same. 

4.4 Scenario Three: S6a/S6d - S6a/S6d interworking scenario 
with two IWFs 

4.4.1 General Description 

This interworking scenario is for S6a/S6d interface based on Diameter, S6a/S6d interface based on Diameter and 
SS7/MAP based roaming agreement with two IWFs in the path. 

With this interworking scenario, two EPS operators can reuse the SS7 based roaming agreement. 

This IWF scenario can only be an inter PLMN use case in which the two IWFs are in the VPLMN and HPLMN 
separately. 

This interworking scenario is described as below: 
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VPLMN (EPS) 



MME/SGSN 



IWF 



SS7/MAP 



S6a/S6d 



HPLMN (EPS) 



IWF 



Rel8 HSS-MME/ 
Rel8 HSS-SGSN 



S6a/S6d 



Figure 4.4.1-1 S6a/S6d - S6a/S6d interworking scenario with two IWFs 

4.4.2 Network Deployments 

This IWF scenario will apply the following network deployment situation: 

- Users of a Pre Rel8 UMTS/GPRS/EPS for UTRAN/GERAN and E-UTRAN network access into a visited EPS 
with only E-UTRAN, which is described as below: 




Figure 4.4.2-1 IWF Scenario three network deployment: visited EPS with E-UTRAN only, home EPS 
with E-UTRAN and UTRAN/GERAN and Pre Rel8 UMTS/GPRS 

The subscription data for Pre RelS Gn/Gp SGSN, subscription data for SGSN and the subscription data for MME is 
downloaded to MME. MME picks up the subscription data for MME and discards the subscription data for Pre RelS 
UMTS/GPRS and the subscription data for SGSN. 

- Users of a Pre RelS UMTS/GPRS/EPS for UTRAN/GERAN and E-UTRAN network access into a visited EPS 
with E-UTRAN and UTRAN/GERAN, which is described as below: 
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Figure 4.4.2-2 IWF Scenario three network deployment: visited EPS with E-UTRAN only and 
UTRAN/GERAN, home EPS with E-UTRAN and UTRAN/GERAN and Pre Rel8 UMTS/GPRS 

The subscription data for Pre Rel8 Gn/Gp SGSN, subscription data for SGSN and the subscription data for MME is 
downloaded to SGSN or MME. SGSN or MME picks up the subscription data forSGSN or MME and discards the 
subscription data for Pre Rel8 UMTS/GPRS and the subscription data for MME or SGSN. 

- Users of an EPS for UTRAN/GERAN and E-UTRAN network access into a visited EPS with only E-UTRAN, 
which is described as below: 




Figure 4.4.2-3 IWF Scenario three network deployment: visited EPS with E-UTRAN only, home EPS 

with E-UTRAN and UTRAN/GERAN 

The subscription data for SGSN and the subscription data for MME is downloaded to MME. MME picks up the 
subscription data for MME and discards the subscription data for the subscription data for SGSN. 

- Users of an EPS for UTRAN/GERAN and E-UTRAN network access into a visited EPS with E-UTRAN and 
UTRAN/GERAN, which is described as below: 
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Figure 4.4.2-4 IWF Scenario three network deployment: visited EPS with E-UTRAN and 
UTRAN/GERAN, home EPS with E-UTRAN and UTRAN/GERAN 

The subscription data for SGSN and the subscription data for MME is downloaded to SGSN or MME. SGSN or MME 
picks up the subscription data for SGSN or MME and discards the subscription data for MME or SGSN. 

- Users of a Pre Rel8 UMTS/GPRS/EPS for E-UTRAN only network access into a visited EPS with only E- 
UTRAN, which is described as below: 




S6a/^ 


\ 




"^-\ 


\ 


Rel8 
HSS 




) 


MME 








Gn/Gp 
-^GSN 







Pre Rel8 
UTRAN 



Pre Rel8 
GERAN 



Figure 4.4.2-5 IWF Scenario three network deployment: visited EPS with E-UTRAN only, home ESP 

with E-UTRAN only and Pre Rel8 UMTS/GPRS 

The subscription data for Pre RelS Gn/Gp SGSN and the subscription data for MME is downloaded to MME. MME 
picks up the subscription data for MME and discards the subscription data for Pre RelS Gn/Gp SGSN. 

NOTE: This IWF scenario can not be used for interworking between two EPS network with only E-UTRAN in 
which there in no MAP based roaming agreement to be reused. 
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4.5 Scenario Four: S13/S13' - Gf interworking scenario with one 
IWF 

4.5.1 General Description 

This interworking scenario is for S13/S13' interface based on Diameter and Gf interface based on MAP with one IWF 
in the path. 

This IWF scenario can only be an intra PLMN use case for operator to do the partly update of their legacy network. 

This interworking scenario is described as below: 

V or HPLMN (EPS) 



MME/SGSN 




IWF 




Pre Rel8 EIR 







S13/S13' 



Gf 



Figure 4.5.1-1 S13/S13' - Gf interworking scenario with one IWF 

4.5.2 Network Deployments 

This IWF scenario will apply the following network deployment situation: 

- ME identity/IMEISV of a user from a Pre Rel8 UMTS/GPRS network can be checked in a visited EPS with E- 
UTRAN only, which is described as below: 




UE 



Figure 4.5.2-1 IWF Scenario for network deployment: UE access from EPS with E-UTRAN only 

- ME identity/IMEISV of a user from a Pre Rel8 UMTS/GPRS network can be checked in a visited EPS with E- 
UTRAN and UTRAN/GERAN, which is described as below: 
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UE 



Figure4.5.2-2 IWF Scenario for networl< deployment: UE access from EPS with E-UTRAN and 

UTRAN/GERAN 



General issues 



5.1 Message Routing Meciianism 

The principles for IWF message routing are: 

- For the same user, the messages shall go to and come back through the same route with the same IWF(s) for the 
duration of a MAP dialog. 

- To ensure the correct message routing for the interworking scenarios, the IWFs in the network shall be able to map 
the SS7 number and the Diameter identity of the MME/SGSN 1-to-l. This may be achieved by static or dynamic 
configuration. 

- To ensure the parallel multiple request messages can get their correct response messages, the IWFs in the network 
shall be able to map the MAP Dialogue Id and the Diameter Session Id 1-to-l. 

The overall message routing mechanism for the scenario is described as below: 

1. The MME/SGSN may not be able to identify whether there is an IWF or not on the route to an HSS. The routing 
of the first message from the MME/SGSN to the IWF/HSS is the same as for a normal Diameter message 
routing. If the MME/SGSN knows the address/name of the IWF/HSS for a certain user, both the Destination- 
Realm and Destination-Host AVPs shall be present in the request. Otherwise, only the Destination-Realm AVP 
shall be present and the command shall be routed to the next Diameter node based on the Diameter routing table 
in the client. 

When the MME/SGSN receives an answer message from the IWF/HSS, it should store the identity of the 
IWF/HSS for each IMSI for future reference to be able to send messages for the same IMSI. 

2. The IWF shall assign an SS7 number for the Diameter node MME/SGSN and shall assign a Diameter identity 
for the SS7 node HSS. This may be achieved by static configuration or dynamic assignment when the first 
signalling exchange occurs between the Diameter/SS7 nodes and the IWF. The IWF shall maintain a mapping 
table (address mapping table) for the assignment relationship. 
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When a Diameter message reaches the IWF to set up a new Diameter session, the IWF(s) shall allocate a MAP 
Dialogue Id for the Diameter session. The IWF(s) shall maintain a mapping table (session mapping table) 
between the MAP Dialogue Id and the Diameter Session Id. 

The IWF shall then process messages as described below: 

a. When the IWF receives a Diameter message from a Diameter node, it shall map the Diameter message to a 
MAP message. It shall obtain a MAP Dialogue Id from the Diameter Session Id in the received message 
according to the session mapping table. The IWF shall obtain the source/destination SS7 Number from the 
source/destination Diameter Identity in the received message according to the address mapping table. 

b. When the IWF receives an SS7 message from an SS7 node, it shall map the MAP message to a Diameter 
message. It shall obtain the Diameter Session Id from the MAP Dialogue Id in the received message 
according to the session mapping table. The IWF shall obtain the source/destination Diameter Identity from 
the source/destination SS7 Number in the received message according to the address mapping table. 

3. When the HSS/HLR receives the first message from IWF/SGSN, the HSS/HLR shall record the SS7 number of 
the source for future message handling. 



5.2 



Void 



5.3 Security Consideration for IWF 



To support the full EPS-AKA security level for the related IWF scenarios, the Pre Rel8 HLR shall be upgraded so that 
E-UTRAN authentication vector requests from nodes serving E-UTRAN can be identified. The detailed mechanism is 
described in 3GPP TS 33.401 [2]. 



The Interworking Scenarios 



6.1 



One IWF scenario 



In this scenario, one IWF is located between MME or SGSN or combined MME/SGSN and HSS or one IWF is located 
between MME and FIR, as illustrated in figure 6.1-1: 



MME or 

SGSN or 

Combined MME/SGSN 



S6a/S6d 



IWF 



Gr 




MME or 

SGSN or 

Combined MME/SGSN 



S13/S13' 



IWF 



Gf 



> EIR 



Figure 6.1 .-1 : One IWF scenarios 

The IWF needs not to be aware whether its connection via Gr is to an HSS or to a second IWF (see Two IWF scenario). 

6.2 Two IWF scenario 

In this scenario, two IWFs are located between MME or SGSN or combined MME/SGSN and HSS, as illustrated in 
figure 6.2-1: 
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MMEor 

SGSN or 

Combined MME/SGSN 



-S6a/S6d- 




-Gr- 




S6a/S6d 




Figure 6.2-1 : Two IWFs scenario 

The IWFl is located in the VPLMN. IWF2 is located in the HPLMN. The IWFl needs not to be aware whether its 
connection via Gr is to an IWF or to an HSS (see One IWF scenario). 



7.1 



The Mapping of the Procedures 



Authentication Information Retrieval 



7.1.1 One IWF Scenario 

The mapping of procedures for this scenario is shown in figure 7.1.1-1: 

S6a/S6d 





Gr 



-1. AIR- 



'S. AIA- 




-2. SendAuthenticationlnfo- 



3. Dialogue Continuation- 



-4. Send Authentication Info Ack- 



Figure 7.1.1-1 : Mapping of Authentication Info Retrieval Procedure for scenario with one IWF 

1 . The IWF receives an AIR message from the MME, SGSN or combined MME/SGSN. 

2. The IWF opens a MAP v3 dialogue towards the HSS by sending SendAuthenticationlnfo. 

3. The HSS may initiate MAP version fallback and/or send partial results. The IWF performs the version fallback 
and/or stores the partial results. If EPS -Vectors are requested for inmiediate use, version fallback is not 
applicable; 

4. The HSS closes the MAP dialogue by sending the (final) SendAuthenticationlnfo Ack to the IWF. 

5. The IWF uses the information received from the HSS to construct an AIA which is sent to the MME, SGSN, or 
combined MME/SGSN. 
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7.1 .2 Two IWFs Scenario 

The mapping of procedures for this scenario is shown in figure 7.1.2-1: 

S6a/S6d 




Gr 



IWF2 



2. SendAuthenticationlnfo- 



5. Dialogue Continuation- 



< 6. SendAuthenticationlnfo Ack- 



S6a/S6d 



HSS 



-3. AIR ► 



< 4.AIA- 



Figure 7.1.2-1 : Mapping of Authentication Info Retrieval Procedure for scenario with two IWFs 

1. The IWFl receives an AIR message from the MME, SGSN or combined MME/SGSN. 

2. The IWFl opens a MAP v3 dialogue towards IWF2 by sending SendAuthenticationlnfo. 

3. The IWF2 constructs an AIR message and sends it to the HSS. 

4. The IWF2 receives AIA from the HSS. 

5. If segmentation is required, the IWF2 sends partial results to the IWFl which stores the partial results. 

6. The IWF2 closes the MAP dialogue by sending the (final) SendAuthenticationlnfo Ack to IWFl. 

7. The IWFl uses the information received from the IWF2 to construct an AIA which is sent to the MME, SGSN, 
or combined MME/SGSN. 

7.2 Update Location 
7.2.1 One IWF Scenario 

The mapping of procedures for this scenario is shown in figure 7.2.1-1: 
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MMEor 

SGSN or 

Combined MME/SGSN 



S6a/S6d 




Gr 





2. UpdateGprsLocation- 



3. Dialogue Continuation- 



4. UpdateGprsLocation Ack- 



Figure 7.2.1-1 : Mapping of Update Location Procedure for scenario with one IWF 

1 . The IWF receives an ULR message from the MME, SGSN or combined MME/SGSN. 

2. The IWF shall open a MAP v3 dialogue towards the HSS by sending UpdateGprsLocation. 

3. Depending on "skip subscriber data" indication received in the ULR (bullet 1 aboveand hence sent as per bullet 2 
in the UpdateGprsLocation), the HSS may continue the MAP dialogue by sending one or several 
InsertSubscriberData messages (in acknowledgement mode or in burst mode) to the IWF. The IWF then 
temporarily stores the received data and sends InsertSubscriberData Ack messages to the HSS. 

Note that the HSS may send InsertSubscriberData messages although a "skip subscriber data" indication was 
present. In this case InsertSubscriberData messages received from the HSS shall be acknowledged but need not 
be stored in the IWF. 

When sending InsertSubscriberData Ack messages to the HSS the IWF shall mirror back any services requested 
by the HSS (within the InsertSubscriberData message) but not supported by the MME or SGSN or combined 
MME/SGSN (as indicated in l.ULR). The IWF shall reject a MAP ActivateTraceMode message received from 
the HSS by returning ActivateTraceMode Error (facilityNotSupported). 

If the IWF received a MAP ActivateTraceMode message from the HSS, the IWF needs to store the received 
trace data. Based upon support of tracing (as indicated the ULR received in bullet 1 above), the MME/SGSN 
sends an ActivateTraceMode Result (positive Ack) or Error FacilityNotSupported (negative Ack) to the HSS. 

4. The HSS shallclose the MAP dialogue by sending UpdateGprsLocation Ack to the IWF. 

5. The IWF shal use the information received from the HSS to construct an ULA which is sent to the MME, SGSN, 
or combined MME/SGSN. 

7.2.2 Two IWFs Scenario 

The mapping of procedures for this scenario is shown in figure 7.2.2-1: 
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Gr 



-2. UpdateGprsLocation- 



- 5. Dialogue Continuation- 



IWF2 



< 6. UpdateGprsLocation Ack- 



S6a/S6d 



HSS 



-3.ULR ► 



< 4.ULA- 



Figure 7.2.2-1 : Mapping of Update Location Procedure for scenario with two IWFs 

1. The IWFl receives an ULR message from the MME, SGSN or combined MME/SGSN. 

2. The IWFl shall open a MAP v3 dialogue towards IWF2 by sending UpdateGprsLocation. 

3. The IWF2 shall construct a ULR message and shall send it to the HSS. 

4. The IWF2 receives ULA from the HSS. 

5. If subscriber data is included in the ULA(as per bullet 4), the IWF2 shall send one or several 
InsertSubscriberData messages (in acknowledgement mode or in burst mode) to the IWFL IWFl then 
temporarily stores the received data and sends InsertSubscriberData Ack messages to the IWF2. If trace data is 
included in the ULA (bullet 4. above) , the IWF2 sends an ActivateTraceMode message to the IWFl, which 
sends an ActivateTraceMode Ack message to the IWF2. 

6. The IWF2 shall close the MAP dialogue by sending UpdateGprsLocation Ack to IWFl. 

7. The IWFl shall use the information received from the IWF2 to construct an ULA which shall be sent to the 
MME, SGSN, or combined MME/SGSN. 



7.3 



Cancel Location 



7.3.1 One IWF Scenario 

The mapping of procedures for this scenario is shown in figure 7.3.1-1: 
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MMEor 

SGSN or 

Combined MME/SGSN 



S6a/S6d 





Gr 



-LCancelLocation- 




-4. CancelLocationAck- 



Figure 7.3.1-1 : Mapping of Cancel Location Procedure for scenario with one IWF 

1. The IWF receives a CancelLocation MAP v3 message from the HSS (the IWF shall reject CancelLocation 
messages in version <3 and shall initiate version fallback when receiving CancelLocation messages in versions 
>3; not shown in figure 7.3.1-1). 

2. The IWF sends CLR to the MME or SGSN or combined MME/SGSN. 

3. The IWF receives CL A. 

4. The IWF closes the MAP dialogue with the HSS by sending CancelLocation Ack. 

7.3.2 Two IWFs Scenario 

The mapping of procedures for this scenario is shown in figure 7.3.2-1: 
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S6a/S6d 



IWF1 




Gr 



IWF2 



-2. CancelLocation- 



-5. CancelLocation Ack- 



S6a/S6d 



HSS 



< 1.CLR- 



-6.CLA ► 



Figure 7.3.2-1 : Mapping of Cancel Location Procedure for scenario with two IWFs 

1 . The IWF2 receives a CLR message from the HSS. 

2. The IWF2 opens a MAP v3 dialogue towards IWFl by sending CancelLocation. 

3. The IWFl constructs a CLR message and sends it to the MME, SGSN, or combined MME/SGSN. 

4. The IWFl receives CLA from the MME, SGSN or combined MME/SGSN. 

5. The IWFl closes the MAP dialogue with the IWF2 by sending CancelLocation Ack. 

6. The IWF2 sends CLA to the HSS. 

7.4 Purge 

7.4.1 One IWF Scenario 

The mapping of procedures for this scenario is shown in figure 7.4.1-1: 
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MMEor 

SGSN or 

Combined MME/SGSN 



S6a/S6d 




-1.PUR- 



-4. PUA- 



Gr 




-2. PurgeMS- 



-S.PurgeMSAck- 



Figure 7.4.1-1 : Mapping of Purge Procedure for scenario with one IWF 

1. The IWF receives a PUR message from the MME, SGSN, or combined MME/SGSN. 

2. The IWF opens a MAP v3 dialogue towards the HSS by sending PurgeMS. 

3. The IWF receives PurgeMS Ack from the HSS. 

4. The IWF sends PUA to the MME, SGSN, or combined MME/SGSN. 

7.4.2 Two IWFs Scenario 

The mapping of procedures for this scenario is shown in figure 7.4.2-1: 
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Gr 



IWF2 



-2. PurgeMS- 



S.PurgeMSAck- 



S6a/S6d 



HSS 



-3, PUR ► 



< 4. PUA- 



Figure 7.4.2-1 : Mapping of Purge Procedure for scenario with two IWFs 

1. The IWFl receives a PUR message from the MME, SGSN, or combined MME/SGSN. 

2. The IWFl opens a MAP v3 dialogue towards IWF2 by sending PurgeMS. 

3. The IWF2 constructs a PUR message and sends it to the HSS. 

4. The IWF2 receives PUA from the HSS. 

5. The IWF2 closes the MAP dialogue with the IWFl by sending PurgeMS Ack. 

6. The IWFl sends PUA to the MME, SGSN, or combined MME/SGSN. 



7.5 



Insert Subscriber Data 



7.5.1 One IWF Scenario 

The mapping of procedures for this scenario is shown in figure 7.5.1-1: 
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MMEor 

SGSN or 

Combined MME/SGSN 



S6a/S6d 




Gr 



-2. IDR- 
-3. IDA- 




-1 . InsertSubscriberData/ProvideSubscriberlnfo — 



-4. InsertSubscriberData/ProvideSubscriberlnfo Ack" 



5. Steps 1 to 4 may be repeated several times for InsertSubscriberData 



-6. END- 



Figure 7.5.1-1 : Mapping of Insert Subscriber Data Procedure for scenario with one IWF 

1. The IWF receives an (stand alone) InsertSubscriberData or ProvideSubscriberlnfo message from the HSS. 

2. The IWF constructs an IDR message and sends it to the MME, SGSN, or combined MME/SGSN. 

3. The IWF receives IDA from the MME, SGSN, or combined MME/SGSN. 

4. The IWF sends InsertSubscriberData or ProvideSubscriberlnfo Ack to the HSS. 

5. Steps 1 to 4 may be repeated several times for InsertSubscriberData. The repetition may be in burst mode or in 
acknowledge mode. 

6. The HSS closes the MAP dialogue. 

NOTE: In a mapping procedure, the IWF correlates the MAP Dialogue ID of the MAP request message and the 
Diameter Session-ID of the mapped Diameter request message which is to be used in the subsequent 
mapping from Diameter Answer message to corresponding MAP Ack message. 



7.5.2 Two IWFs Scenario 

The mapping of procedures for this scenario is shown in figure 7.5.2-1: 
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S6a/S6d 



IWF1 



-3. IDR- 



-i IDA- 



Gr 



-2. InsertSubscriberData/ProvideSubscriberlnfo- 



-5. InsertSubscriberData/ProvideSubscriberlnfo Ack" 



. steps 2 to 5 may be repeated several times for InsertSubscriberData- 
N 7. END 




Figure 7.5.2-1 : Mapping of Insert Subscriber Data Procedure for scenario with two IWFs 

1 . The IWF2 receives a IDR message from the HSS. 

2. The IWF2 opens a MAP v3 dialogue towards IWFl by sending InsertSubscriberData (if the IDR-Flags AVP 
within the IDR is not present or the "UE ReachabiHty Request" flag was set in the IDR-Flags AVP within the 
IDR) or ProvideSubscriberlnfo in other cases. If segmentation of the data (on MAP level) is required the IWF2 
temporarily stores the data that could not be sent in this step. 

3. The IWFl constructs a IDR message and sends it to the MME, SGSN, or combined MME/SGSN. 

4. The IWFl receives IDA from the MME, SGSN, or combined MME/SGSN. 

5. The IWFl sends InsertSubscriberData or ProvideSubscriberlnfo Ack to IWF2. 

6. If segmentation is required for InsertSubscriberData, steps 2 to 5 are be repeated until all data are sent. 
Repetition may be in burst mode or in acknowledge mode. 

7. IWF2 closes the MAP dialogue with IWFl . 

8. IWF2 sends IDA to the HSS. 

NOTE: In a mapping procedure, the IWFs correlates the MAP Dialogue ID of the MAP request message and the 
Diameter Session-ID of the mapped Diameter request message which is to be used in the subsequent 
mapping from Diameter Answer message to corresponding MAP Ack message or vice versa. 



7.6 



Delete Subscriber Data 



7.6.1 One IWF Scenario 

The mapping of procedures for this scenario is shown in figure 7.6.1-1: 
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MMEor 

SGSN or 

Combined MME/SGSN 



S6a/S6d 




-2. DSR- 



-3. DSA- 



Gr 



-1 . DeleteSubscriberData- 




-4. DeleteSubscriberData Ack- 



Figure 7.6.1-1 : Mapping of Delete Subscriber Data Procedure for scenario with one IWF 

1. The IWF receives a DeleteSubscriberData MAP v3 message from the HSS (the IWF shall reject 
DeleteSubscriberData messages in version <3 and shall initiate version fallback when receiving 
DeleteSubscriberData messages in versions >3; not shown in figure 7.6.1-1). 

2. The IWF sends DSR to the MME or SGSN or combined MME/SGSN. 

3. The IWF receives DS A. 

4. The IWF closes the MAP dialogue with the HSS by sending DeleteSubscriberData Ack. 

7.6.2 Two IWFs Scenario 

The mapping of procedures for this scenario is shown in figure 7.6.2-1: 
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S6a/S6d 



IWF1 




Gr 



IWF2 



-2. DeleteSubscriberData- 



-5. DeleteSubscriberData Ack ► 



S6a/S6d 



HSS 



< 1.DSR- 



-6.DSA ► 



Figure 7.6.2-1 : Mapping of Delete Subscriber Data Procedure for scenario with two IWFs 

1 . The IWF2 receives a DSR message from the HSS. 

2. The IWF2 opens a MAP v3 dialogue towards IWFl by sending DeleteSubscriberData. 

3. The IWFl constructs a DSR message and sends it to the MME, SGSN, or combined MME/SGSN. 

4. The IWFl receives DSA from the MME, SGSN or combined MME/SGSN. 

5. The IWFl closes the MAP dialogue with the IWF2 by sending DeleteSubscriberData Ack. 

6. The IWF2 sends DSA to the HSS. 



7.7 



Reset 



7.7.1 One IWF Scenario 

The mapping of procedures for this scenario is shown in figure 7.7.1-1: 
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MMEor 

SGSN or 

Combined MME/SGSN 



S6a/S6d 




-2. RSR- 



-3. RSA- 



Gr 



-1. Reset- 




Figure 7.7.1-1 : IVIapping of Reset Procedure for scenario witli one IWF 

1. The IWF receives a Reset MAP vl or v2 message from the HSS. 

2. The IWF sends RSR to the MME or SGSN or combined MME/SGSN. 

3. The IWF receives RSA. 

7.7.2 Two IWFs Scenario 

The mapping of procedures for this scenario is shown in figure 7.7.2-1: 

S6a/S6d IWF1 Gr 




-4.RSR- 



-5, RSA- 



IWF2 



-2, Reset- 



S6a/S6d 



HSS 



^ 1,RSR- 



-3. RSA- 



Figure 7.7.2-1 : Mapping of Reset Procedure for scenario with two IWFs 

1. The IWF2 receives a RSR message from the HSS. 

2. The IWF2 opens a MAP vl or v2 (vendor option) dialogue towards IWFl by sending Reset. 

3. The IWF2 sends RSA to the HSS. 

4. The IWFl constructs a RSR message and sends it to the MME, SGSN, or combined MME/SGSN. 

5. The IWFl receives RSA from the MME, SGSN or combined MME/SGSN. 
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7.8 



Notification 



7.8.1 One IWF Scenario 

The mapping of procedures for this scenario is shown in figure 7.8.1-1: 

S6a/S6d 



MMEor 

SGSN or 

Combined MME/SGSN 




Gr 



-1.N0R- 



-3. NOA- 




-2. UpdateGprsLocation- 



4. dialogue continuation- 



-5. UpdateGprsLocation Ack- 



Figure 7.8.1-1 : Mapping of Notification Procedure for scenario witli one IWF 

1 . The IWF receives a NOR message from the MME, SGSN, or combined MME/SGSN. 

2. The IWF sends UpdateGprsLocation or ReadyForSM to the HSS. 

3. The IWF sends NO A to the MME, SGSN, or combined MME/SGSN. 

4. The HSS (if it does not support the "skip subscriber data" indication) may continue the MAP dialogue by 
sending InsertSubscriberData messages which are positively acknowledged and discarded by the IWF. 

5. The HSS closes the MAP dialogue by sending UpdateGprsLocation Ack or ReadyForSM Ack. 

7.8.2 Two IWFs Scenario 

The mapping of procedures for this scenario is shown in figure 7.8.2-1: 
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Gr 



2. UpdateGprsLocation- 



5. UpdateGprsLocation Ack- 



IWF2 



S6a/S6d 



< 6.N0A- 



HSS 



-4. NOR ► 



Figure 7.8.2-1 : Mapping of Notification Procedure for scenario with two IWFs 

1. The IWFl receives a NOR message from the MME, SGSN, or combined MME/SGSN. 

2. The IWFl sends UpdateGprsLocation or ReadyForSM to the IWF2. 

3. The IWFl sends NOA to the MME, SGSN, or combined MME/SGSN. 

4. The IWF2 sends NOR to the HSS. 

5. The IWF2 closes the MAP dialogue with IWFl by sending UpdateGprsLocation Ack or ReadyForSM Ack. 

6. The IWF2 receives NOA from the HSS. 



7.9 



IMEI Check 



7.9.1 One IWF Scenario 

The mapping of procedures for this scenario is shown in figure 7.9.1-1: 
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MMEor 

SGSNor 

Combined MME/SGSN 



S13/S13' 



1. ECR 



4. EGA 



IWF 



Of 




2. Check IMEI 



3. Check IMEI Ack 



Figure 7.9.1-1 : Mapping of IMEI Check Procedure with one IWF 

1 . The IWF receives an ECR message from the MME/SGSN. 

2. The IWF sends Check IMEI to the FIR. 

3. The IWF receives Check IMEI Ack from the FIR. 

4. The IWF sends EGA to the MME/SGSN. 



7.10 Trace Activation 



7.10.1 One IWF Scenario 

The mapping of procedures for this scenario is shown in figure 7.10.1-1: 
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MMEor 

SGSN or 

Combined MME/SGSN 



S6a/S6d 





Gr 




-1 . ActivateTraceMode- 



-4. ActivateTraceMode Ack- 



Figure 7.10.1-1 : Mapping of Trace Activation Procedure for scenario with one IWF 

1 . The IWF receives an ActivateTraceMode message from the HSS. 

2. The IWF shall construct an IDR message and send it to the MME, SGSN, or combined MME/SGSN. 

3. The IWF receives IDA from the MME, SGSN, or combined MME/SGSN. 

4. The IWF shall send an ActivateTraceMode Ack to the HSS. 
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7.10.2 Two IWFs Scenario 



MMEor 

SGSN or 

Combined MME/SGSN 



S6a/S6d 




Gr 



-3. IDR- 



-4. IDA- 




-2. AdivateTraceMode- 



-5. ActivateTraceMode Ack- 



S6a/S6d 



-1.IDR- 




-6. IDA- 



Figure 7.10.2-1 : Mapping of Trace Activation Procedure for scenario with two IWFs 

1. The IWF2 receives an IDR message from the HSS. 

2. If the IWF2 finds that Trace Data is included in the IDR, it shall open a MAP v3 dialogue towards IWFl by 
sending ActivateTraceMode. 

3. The IWFl shall construct an IDR message and shall send it to the MME, SGSN, or combined MME/SGSN. 

4. The IWFl receives IDA from the MME, SGSN, or combined MME/SGSN. 

5. The IWFl shall send an ActivateTraceMode Ack to IWF2. 

6. IWF2 shall send an IDA to the HSS. 



7.11 Trace Deactivation 
7.11.1 One IWF Scenario 

The mapping of procedures for this scenario is shown in figure 7.11.1-1: 
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MMEor 

SGSN or 

Combined MME/SGSN 



S6a/S6d 




Gr 



-2. DSR- 



-3. DSA- 




-1 . DeactivateTraceMode- 



-4. DeactivateTraceMode Ack- 



Figure 7.11.1-1 : Mapping of Trace Deactivation Procedure for scenario with one IWF 

1 . The IWF receives a DeactivateTraceMode message from the HSS. 

2. The IWF shall construct a DSR message and shall send it to the MME, SGSN, or the combined MME/SGSN. 

3. The IWF receives DSA from the MME, SGSN, or combined MME/SGSN. 

4. The IWF shall send a DeactivateTraceMode Ack to the HSS. 
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7.11.2 Two I WFs Scenario 



MMEor 

SGSN or 

Combined MME/SGSN 



S6a/S6d 




Gr 



-3. DSR- 



-4. DSA- 




-2. DeactivateTraceMode- 



-5. DeactivateTraceMode Ackn 



S6a/S6d 



-1.DSR- 




-6. DSA- 



Figure 7.11.2-1 : Mapping of Trace Deactivation Procedure for scenario with two IWFs 

1 . The IWF2 receives a DSR message from the HSS. 

2. If the IWF2 finds that a Trace Data Withdrawal indication is included in the DSR, it shall open a MAP v3 
dialogue towards IWFl by sending DeactivateTraceMode. 

3. The IWFl shall construct a DSR message and shall send it to the MME, SGSN, or the combined MME/SGSN. 

4. The IWFl receives DSA from the MME, SGSN, or combined MME/SGSN. 

5. The IWFl shall send a DeactivateTraceMode Ack to the IWF2. 

6. The IWF2 shall send a DSA to the HSS. 



8 The Mapping of the Parameters 

8.1 Mapping of Parameters for the Authentication Info Retrieval 
Procedure 

8.1 .1 AIR mapping to SendAuthenticationlnfoArg (v3) 

When the IWF needs to construct a MAP-SendAuthenticationlnfo message as a result of receiving an AIR command 
(see sections 7.1.1 step 2, and 7.1.2 step 2), the IWF shall open a MAP dialogue in application context version 3 and 
populate sub-parameters of SendAuthenticationlnfoArg as described below: 

imsi in SendAuthenticationlnfoArg shall be populated with the value of the User-Name AVP received within AIR. 

If AIR contains a Requested-EUTRAN- Authentication-Info AVP but does not contain a Requested-UTRAN-GERAN- 
Authentication-Info AVP: 
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numberOfRequestedVectors in SendAuthenticationlnfoArg shall be populated with the value of the Number-Of- 
Requested- Vectors AVP received within the Requested-EUTRAN- Authentication-Info AVP received within AIR. 

If AIR contains a Requested-UTRAN-GERAN- Authentication-Info AVP but does not contain a Requested-EUTRAN- 
Authentication-Info AVP: 

numberOfRequestedVectors in SendAuthenticationlnfoArg shall be populated with the value of the Number-Of- 
Requested- Vectors AVP received within the Requested-UTRAN-GERAN- Authentication-Info AVP received within 
AIR. 

If AIR contains a Requested-EUTRAN- Authentication-Info AVP and a Requested-UTRAN-GERAN- Authentication- 
Info AVP, and the Immediate-Response-Preferred AVP is present within the Requested-EUTRAN- Authentication-Info 
AVP: 

numberOfRequestedVectors in SendAuthenticationlnfoArg shall be populated with the value of the Number-Of- 
Requested- Vectors AVP received within the Requested-EUTRAN- Authentication-Info AVP received within AIR. 

If AIR contains a Requested-EUTRAN- Authentication-Info AVP and a Requested-UTRAN-GERAN- Authentication- 
Info AVP, and the Immediate-Response-Preferred AVP is not present within the Requested-EUTRAN- Authentication- 
Info AVP: 

numberOfRequestedVectors in SendAuthenticationlnfoArg shall be populated with the value of the Number-Of- 
Requested- Vectors AVP received within the Requested-UTRAN-GERAN- Authentication-Info AVP received within 
AIR. 

segmentationProhibited shall be absent in SentAuthenticationlnfoArg. 

If AIR contains a Requested-EUTRAN- Authentication-Info AVP but does not contain a Requested-UTRAN-GERAN- 
Authentication-Info AVP: 

immediateResponsePreferred in SendAuthenticationlnfoArg shall be present if and only if the Inmiediate-Response- 
Preferred AVP is present within the Requested-EUTRAN- Authentication-Info AVP within AIR. 

If AIR contains a Requested-UTRAN-GERAN- Authentication-Info AVP but does not contain a Requested-EUTRAN- 
Authentication-Info AVP: 

immediateResponsePreferred in SendAuthenticationlnfoArg shall be present if and only if the Immediate-Response- 
Preferred AVP is present within the Requested-UTRAN-GERAN- Authentication-Info AVP within AIR. 

If AIR contains a Requested-EUTRAN- Authentication-Info AVP and a Requested-UTRAN-GERAN- Authentication- 
Info AVP: 

immediateResponsePreferred in SendAuthenticationlnfoArg shall be present if and only if the Immediate-Response- 
Preferred AVP is present within the Requested-UTRAN-GERAN- Authentication-Info AVP or within the Requested- 
EUTRAN- Authentication-Info AVP within AIR. 

re-synchronisationlnfo in SendAuthenticationlnfoArg shall be present if and only if a Re-synchronization-Info AVP is 
present wihin the Requested-EUTRAN- Authentication-Info AVP or within the Requested-UTRAN-GERAN- 
Authentication-Info AVP within AIR. 

extensionContainer in SendAuthenticationlnfoArg shall be absent. 

requestingNodeXype in SendAuthenticationlnfoArg shall be present and shall be populated with the value 

"mme" if a Requested-EUTRAN- Authentication-Info AVP and no Requested-UTRAN-GERAN- Authentication- 
Info AVP was present within AIR; 

"sgsn" if a Requested-UTRAN-GERAN- Authenticatio-Info AVP and no Requested EUTRAN- Authentication-Info 
AVP was present within AIR; 

. "mme-sgsn" if both a Requested-EUTRAN- Authentication-Info AVP and a Requested-UTRAN-GERAN- 
Authentication-Info AVP were present within AIR . 

requestingPLMN-Id in SendAuthenticationlnfoArg shall be present and shall be populated with the value received 
within the Visited-PLMN-ID AVP within AIR. 

numberOfRequestedAdditional-Vectors in SendAuthenticationlnfoArg shall be present if and only if both a 
Requested-EUTRAN- Authentication-Info AVP and a Requested-UTRAN-GERAN- Authentication-Info AVP are 
present within AIR. If present, the parameter shall be populated with the value received in the Number- Of-Requested- 
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Vectors AVP within the Requested-EUTRAN- Authentication-Info (if the Immediate-Response-Preferred AVP is absent 
within Requested-EUTRAN- Authentication-Info AVP within AIR) or with the value received in the Number-Of- 
Requested- Vectors AVP within the Requested-UTRAN-GER AN- Authentication-Info AVP (otherwise). 

additionalVectorsAreForEPS shall be present in SendAuthenticationlnfoArg if and only if a Requested-EUTRAN- 
Authentication-Info AVP and a Requested-UTRAN-GERAN- Authentication-Info AVP are present within AIR and the 
Immediate-Response-Preferred AVP is absent in the Requested-EUTRAN- Authentication-Info AVP. 

8.1 .2 AIR mapping to SendAuthenticationlnfoArg (v2) 

When the IWF needs to construct a MAP-SendAuthenticationlnfo message in MAP AC version 2 as a result of MAP 
version negotiation (see sections 7.1.1 step 3), the IWF shall open a MAP dialogue in application context version 2 and 
populate sub-parameters of SendAuthenticationlnfoArg as described below: 

imsi in SendAuthenticationlnfoArg shall be populated with the value of the User-Name AVP received within AIR. 

8.1.3 AIR mapping to SendParametersArg (v1) 

When the IWF needs to construct a MAP-SendParameters message in MAP AC version 1 as a result of MAP version 
negotiation (see section 7.1.1 step 3), the IWF shall open a MAP dialogue in application context version 1 and populate 
sub-parameters of SendParametersArg as described below: 

subscriberld in SendParametersArg shall take the imsi alternative; imsi shall be populated with the value of the User- 
Name AVP received within AIR. 

requestedParameterList in SendParametersArg shall contain one RequestParameter which contains the value of 
"requestAuthenticationSet" . 

8.1 .4 SendAuthenticationlnfoRes / Error (v3) mapping to AIA 

When the IWF needs to construct an AIA command as a result of receiving a SendAuthenticationlnfo Ack/Error 
message in MAP version 3 (see sections 7.1.1 step 5, and 7.1.2 step 7), the IWF shall populate AVPs of AIA as 
described below: 

Result- Code / Experimental-Result AVP shall be set to: 

- DIAMETER_SUCCESS if a SendAuthenticationlnfoRes parameter was received in a TCAP ResultLast 
component; 

- DIAMETER_ERROR_USER_UNKNOWN if an error of unknownSubscriber without a diagnostic parameter or 
with a diagnostic parameter of imsiUnknown was received; 

- DIAMETER_ERROR_UNKNOWN_SUBSCRIPTION if an error unknownSubscriber with a diagnostic 
parameter of gprs-eps-SubscriptionUnknown was received; 

- an appropriate DIAMETER base protocol result code otherwise. 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

Supported-Features AVP shall be absent. 

Authentication-Info AVP shall be present if authenticationSetList or eps- Authentications etList is present in the 
received SendAuthenticationlnfoRes. If present, the AVP shall contain EPS-Vector AVPs and/or either UTRAN- Vector 
AVPs or GERAN- Vector AVPs as mapped from received EPC-AVs and/or either AuthenticationQuintuplets or 
AuthenticationTriplets respectively. 

8.1 .5 SendAuthenticationlnfoRes / Error (v2) mapping to AIA 

When the IWF needs to construct an AIA command as a result of receiving a SendAuthenticationlnfo Ack/Error 
message in MAP version 2 (see sections 7.1.1 step 5), the IWF shall populate AVPs of AIA as described below: 

Result- Code / Experimental-Result AVP shall be set to: 
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- DIAMETER_SUCCESS if aSendAuthenticationlnfoRes parameter was received in a TCAP ResultLast 
component; 

- DIAMETER_ERROR_USER_UNKNOWN if an error of unknownSubscriber without a diagnostic parameter or 
with a diagnostic parameter of imsiUnknown was received; 

- DIAMETER_ERROR_UNKNOWN_SUB SCRIPTION if an error unknownSubscriber with a diagnostic 
parameter of gprsSubscriptionUnknown was received; 

- an appropriate DIAMETER base protocol result code otherwise. 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

Supported-Features AVP shall be absent. 

Authentication-Info AVP shall be present if authentications etList is present in the received 
SendAuthenticationlnfoRes. If present, the AVP shall contain GERAN- Vector AVPs as mapped from received 
AuthenticationTriplets . 

8.1.6 SendParameterList / Error (v1) mapping to AIA 

When the IWF needs to construct an AIA command as a result of receiving a SendParameters Ack/Error message in 
MAP version 1 (see sections 7.1.1 step 5), the IWF shall populate AVPs of AIA as described below: 

Result-Code / Experimental-Result AVP shall be set to: 

DIAMETER_SUCCESS if a SentParameterList parameter was received in a TCAP ResultLast component; 

DIAMETER_ERROR_USER_UNKNOWN if an error of unknownSubscriber was received; 

an appropriate DIAMETER base protocol result code otherwise. 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

Supported-Features AVP shall be absent. 

Authentication-Info AVP shall be present if sentParameterList is present in the received TCAP ResultLast component. 
If present, the AVP shall contain GERAN- Vector AVPs as mapped from received AuthenticationTriplets. 

8.1 .7 SendAuthenticationlnfoArg (v3) mapping to AIR 

When the IWF needs to construct an AIR command as a result of receiving a SendAuthenticationlnfo message in MAP 
version 3 (see sections 7.1.2 step 3), the IWF shall populate AVPs of AIR as described below: 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

User-Name AVP shall be populated with the value received within the imsi parameter of SendAuthenticationlnfoArg. 

Supported-Features AVP shall be absent. 

Requested-EUTRAN-Authentication-Info AVP shall be present if requestingNodeType parameter within 
SendAuthenticationlnfoArg takes the value of "mme" or "mme-sgsn". 

Number-Of-Requested-Vectors AVP within Requested-EUTRAN- Authentication-Info AVP (if present) shall be 
populated with 

a) the value received within the numberOfRequestedVectors parameter of SendAuthenticationlnfoArg if 
requestingNodeType parameter within SendAuthenticationlnfoArg takes the value of "mme"; 

b) the value received within the numberOfRequestedVectors parameter of SendAuthenticationlnfoArg if 
requestingNodeType parameter within SendAuthenticationlnfoArg takes the value of "mme-sgsn" and the 
additional Vectors AreForEPS parameter is absent from SendAuthenticationlnfoArg; 



ETSI 



3GPP TS 29.305 version 1 1 .3.0 Release 1 1 42 ETSI TS 1 29 305 V1 1 .3.0 (201 2-1 0) 

c) the value received within the numberOfRequestedAdditional- Vectors parameter of SendAuthenticationlnfoArg 
if requestingNodeType parameter within SendAuthenticationlnfoArg takes the value of "mme-sgsn" and the 
additionalVectorsAreForEPS parameter is present within SendAuthenticationlnfoArg. 

Immediate-Response-Preferred AVP within Requested-EUTRAN- Authentication-Info AVP (if present) shall be 
present if: 

a) requestingNodeType parameter within SendAuthenticationlnfoArg takes the value of "mme" and 
immediateResponsePref erred parameter is present in SendAuthenticationlnfoArg, or 

b) requestingNodeType parameter within SendAuthenticationlnfoArg takes the value of "mme-sgsn" and 
additionalVectorsAreForEPS parameter is absent from SendAuthenticationlnfoArg and 
immediateResponsePreferred is present within SendAuthenticationlnfoArg. 

Re-synchronization-Info AVP within Requested-EUTRAN- Authentication-Info AVP (if present) shall be populated 
with the value received in the re-synchronizationlnfo parameter within SendAuthenticationlnfoArg. 

Requested-UTRAN-GERAN-Authentication-Info AVP shall be present if requestingNodeType parameter within 
SendAuthenticationlnfoArg takes the value of "sgsn" or "mme-sgsn". 

Number-Of-Requested- Vectors AVP within Requested-UTRAN-GERAN- Authentication-Info AVP (if present) shall 
be populated with: 

a) the value received within the numberOfRequestedVectors parameter of SendAuthenticationlnfoArg if 
requestingNodeType parameter within SendAuthenticationlnfoArg takes the value of "sgsn"; 

b) the value received within the numberOfRequestedVectors parameter of SendAuthenticationlnfoArg if 
requestingNodeType parameter within SendAuthenticationlnfoArg takes the value of "mme-sgsn" and the 
additionalVectorsAreForEPS parameter is present within SendAuthenticationlnfoArg; 

c) the value received within the numberOfRequestedAdditional- Vectors parameter of SendAuthenticationlnfoArg 
if requestingNodeType parameter within SendAuthenticationlnfoArg takes the value of "mme-sgsn" and the 
additionalVectorsAreForEPS parameter is absent from SendAuthenticationlnfoArg. 

Immediate-Response-Preferred AVP within Requested-UTRAN-GERAN- Authentication-Info AVP (if present) shall 
be present if 

a) requestingNodeType parameter within SendAuthenticationlnfoArg takes the value of "sgsn" and 
immediateResponsePreferred parameter is present in SendAuthenticationlnfoArg, or 

b) requestingNodeType parameter within SendAuthenticationlnfoArg takes the value of "mme-sgsn" and 
additionalVectorsAreForEPS parameter is present from SendAuthenticationlnfoArg and 
immediateResponsePreferred is present within SendAuthenticationlnfoArg. 

Re-synchronization-Info AVP within Requested-EUTRAN- Authentication-Info AVP (if present) shall be populated 
with the value received in the re-synchronizationlnfo parameter within SendAuthenticationlnfoArg. 

Visited-PLMN-Id AVP shall be populated with the value of the requestingPLMN-Id parameter received within 
SendAuthenticationlnfoArg. 

RequestingNodeType AVP shall be populated with the value of the requestingNodeType parameter received within 
SendAuthenticationlnfoArg. 

8.1 .8 AIA mapping to SendAuthenticationlnfoRes/Error (v3) 

When the IWF needs to construct a MAP SendAuthenticationlnfo Ack message (v3) as a result of receiving an AIA 
command (see sections 7.1.2 steps 5 and 6), the IWF shall construct partial result messages (if segmentation is required) 
and a final result message or an error message (if the Result-Code AVP within AIA takes a value different from 
"success"). Sub-parameters of SendAuthenticationlnfoRes shall be populated as described below: 

authenticationSetList within SendAuthenticationlnfoRes shall be present if UTRAN- Vector AVP or GERAN- Vector 
AVP is present in Authentication-Info AVP within AIA. If so the parameter shall be populated with the value received 
within the UTRAN- Vector AVP or GERAN- Vector AVP (whichever is present). 
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eps-AuthenticationSetList within SendAuthenticationlnfoRes shall be present if EPS-Vector AVP is present in 
Authentication-Info AVP within AIA. If so the parameter shall be populated with the values received within the EPS- 
Vector AVP. 

An error of unknownSubscriber with unknownSubscriberParam containing a unknownSubscriberDiagnostic of 
"imsiUnknown" shall be sent if the received AIA command contains an Experimental-Result AVP with a value of "User 
Unknown" . 

An error of unknownSubscriber with unknownSubscriberParam containing a unknownSubscriberDiagnostic of "gprs- 
epsSubscriptionUnknown" shall be sent if the received AIA command contains an Experimental-Result AVP with a 
value of "Unknown EPS Subscription". 

Other values within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate MAP error. 

8.2 Mapping of Parameters for the Update Location Procedure 
8.2.1 ULR mapping to UpdateGprsLocationArg 

When the IWF needs to construct a MAP-UpdateGprsLocation message as a result of receiving an ULR command (see 
sections 7.2.1 step 2, and 7.2.2 step 2), the IWF shall open a MAP dialogue in application context version 3 and 
populate sub-parameters of UpdateGprsLocationArg as described below: 

imsi in UpdateGprsLocationArg shall be populated with the value of the User-Name AVP received within ULR. 

sgsn-Number in UpdateGprsLocationArg shall be populated with the value of the SGSN.Number AVP if present 
within ULR, otherwise it shall be populated with a value locally assigned to the IWF and consistent with SS7 routing 
principles. 

sgsn- Address in UpdateGprsLocationArg shall be populated with the IP-address of the source node sending the ULR 
command. 

extensionContainer in UpdateGprsLocationArg shall be absent. 

sgsn- Capability in UpdateGprsLocationArg shall be populated as follows: 

- solsaSupportlndicator shall be absent; 

- extensionContainer shall be absent; 

- superChargerSupportedlnServingNetworkEntity shall be absent; 

- gprsEnhancementSupportlndicator shall be present; 

- supportedCamelPhases shall be absent or shall indicate no support of any CAMEL phase; 

- supportedLCS-CapabilitySet shall be absent or shall indicate no support of any LCS capability set; 

- offeredCamel4CSIs shall be absent; 

- smsCallBarringSupportlndicator shall be absent; 

- supportedRAT-TypesIndicator shall be present and populated with the value received within the RAT-Type 
AVP in the received ULR; 

- supportedFeatures shall be present if a SupportedFeature AVP was present in the received ULR which indicated 
support of odbs and regsubs. 

informPreviousNetworkEntity in UpdateGprsLocationArg shall be absent; 

ps-LCS-NotSupportedByUE in UpdateGprsLocationArg shall be absent 

v-gmlc-Address in UpdateGprsLocationArg shall be absent. 
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add-info in UpdateGprsLocationArg shall be present if a Terminal-Information AVP was present in the received ULR. 
If present the parameter shall be poulated with the received IMEI and software version; skipSubscriberDataUpdate in 
add-info shall be absent. 

eps-info in UpdateGprsLocationArg shall be present. 

- if the received ULR contained a S6a/S6d indicator within the ULR-Flags AVP. If so, the parameter shall 
contain isr-Information with updateMME indication, and if a Single-Registration-Indication was present in the 
received ULR-Flags AVP then the isr-Information shall also contain a cancels GSN indication, and if an 
InitialAttachlndicator was present in the received ULR-Flags AVP then the isr-Information shall also contain 
initialAttachlndicator; 

- if the received ULR did not contain an S6a/S6d indicator within the ULR-Flags, but an InitialAttachlndicator 
was present within the ULR-Flags AVP. If so, the parameter shall contain isr-Information with 
initialAttachlndicator. 

servingNodeTypelndicator in UpdateGprsLocationArg shall be present if the S6a/S6d-Indicator was present in the 
ULR-Flags AVP within the received ULR. 

skipSubscriberData Update in UpdateGprsLocationArg shall be present if a skip subscriber data indication was 
receive within the ULR-Flags within ULR. 

usedRAT-Type in UpdateGprsLocationArg shall be populate with the value received within the RAT-Type AVP 
within ULR. 

gprsSubscriptionDataNotNeeded in UpdateGprsLocationArg shall be present if bit 3 (GPRS-Subscription-Data- 
Indicator) was not set in the ULR-Flags AVP received within ULR. 

nodeTypelndicator in UpdateGprsLocationArg shall be present if bit 4 (Node-Type-Indicator) was set in the ULR- 
Flags AVP received within ULR. 

areaRestricted in UpdateGprsLocationArg shall be absent. 

ue-reachablelndicator in UpdateGprsLocationArg shall be absent. 

ue-srvcc-Capability in UpdateGprsLocationArg shall be present if a UE-SRVCC-Capability AVP was present in the 
received ULR. If present the parameter shall be populated with the received ue-srvcc-Capability. 

mmeNumberforMTSMS in UpdateGprsLocationArg shall be populated with the value of the MME-Number-for-MT- 
SMS AVP if present within ULR. 

sms-Only in UpdateGprsLocationArg shall be populated with the value of the SMS-Only AVP if present within ULR. 

smsRegisterRequest in UpdateGprsLocationArg shall be populated with the value of the SMS -Register-Request AVP 
if present within ULR. 

8.2.2 

UpdateGprsLocationRes/Error/lnsertSubscriberDataArg/ActivateTra 
ceModeArg mapping to ULA 

When the IWF needs to construct an ULA command as a result of receiving an UpdateGprsLocation Ack/Error message 
(see sections 7.2.1 step 5, and 7.2.2 step 7), the IWF shall populate AVPs of ULA as described below: 

Result- Code / Experimental-Result AVP shall be set to: 

- DIAMETER_SUCCESS if an UpdateGprsLocationRes parameter was received in a TCAP ResultLast 
component; 

- DIAMETER_ERROR_USER_UNKNOWN if an error of unknownSubscriber without a diagnostic parameter or 
with a diagnostic parameter of imsiUnknown was received; 
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- DI AMETER_ERROR_UNKNOWN_SUB SCRIPTION if an error of unkno wnSubscriber with a diagnostic 
parameter of gprs-eps-SubscriptionUnknown was received; 

- DIAMETER_ERROR_RAT_NOT_ALLOWED if an error of roamingNotAllowed with a 
roamingNotAllowedParam containing an additionalRoamingNotAllowedCause of "supportedRAT- 
TypesNotAllowed" was received; 

- DIAMETER_ERROR_RO AMING_NOT_ALLOWED if an error of roamingNotAllowed without 
"supportedRAT-TypesNotAllowed" was received; 

- an appropriate DIAMETER base protocol result code otherwise. 
Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 
Supported-Features AVP shall be absent. 

ULA-Flags AVP: Flags shall be set as follows: 

- Separationlndication shall be set to 1 if the sgsn-mmeSeparationSupported parameter was present within 
UpdateGprsLocationRes; otherwise shall be set to 0. 

- MME Registered for SMS shall be set to 1 if the mmeRegisteredforSMS parameter was present within 
UpdateGprsLocationRes; otherwise shall be set to 0. 

Subscription-Data AVP shall be present if MAP InsertSubscriberData messages have been received from the HSS and 
a "skip-subscriber-Data" indication was not present in the received ULR command or a MAP ActivateTraceMode 
message has been received from the HSS. If present the AVP shall be populated as follows: 

Subscriber status AVP shall be present if a subscriberStatus parameter was present in a received 
SubscriberData parameter within InsertSubscriberDataArg. If so, values shall be mapped appropriately. 

MSISDN AVP shall be present if an msisdn parameter was present in a received SubscriberData parameter 
within InsertSubscriberDataArg. 

STN-SR AVP shall be present if an stn-sr parameter was present in a received EPS-SubscriptionData parameter 
within InsertSubscriberDataArg. 

Network- Access-Mode AVP shall be present if a networkAccessMode parameter was present within 
InsertSubscriberDataArg. 

Operator-Determined-Barring AVP shall be present if an odb-GeneralData parameter was present within an 
odb-Data parameter within a SubscriberData parameter within InsertSubscriberDataArg. 

HPLMN-ODB AVP shall be present if an odb-HPLMN-Data parameter was present within an odb-Data 
parameter within a SubscriberData parameter within InsertSubscriberDataArg. 

Regional-Subscription-Zone-Code AVPs shall be present if ZoneCodes were present within an 
regionalSubscriptionData parameter within a SubscriberData parameter within InsertSubscriberDataArg. 

Access-Restriction-Data AVP shall be present if an accessRestrictionData parameter was present within 
InsertSubscriberDataArg and/or a ho-to-non-3GPP- Access-Not- Allowed parameter was present in an eps- 
SubscriptionData parameter within InsertSubscriberDataArg. 

APN-OI-Replacement AVP shall be present if an apn-oi-Replacement parameter was present within an eps- 
SubscriptionData parameter within InsertSubscriberDataArg. 

3GPP- Charging- Characteristics AVP shall be present if a chargingCharacteristics parameter was present 
within InsertSubscriberDataArg. 

AMBR AVP shall be present if an ambr parameter was present within an eps-SubscriptionData parameter within 
InsertSubscriberDataArg. 

APN- Configuration-Profile AVP shall be present if an apn-ConfigurationProfile parameter was present within 
an eps-SubscriptionData parameter within InsertSubscriberDataArg. 



ETSI 



3GPP TS 29.305 version 1 1 .3.0 Release 1 1 46 ETSI TS 1 29 305 V1 1 .3.0 (201 2-1 0) 

RAT-Frequency-Selection-Priority-ID AVP shall be present if a rfsp-id parameter was present within an eps- 
SubscriptionData parameter within InsertSubscriberDataArg. 

- Trace-Data AVP shall be present if a MAP ActivateTraceMode message has been received from the HSS. Sub- 
AVPs in Trace-Data AVP shall be populated as follows: 

- Trace-Reference AVP shall be present and populated with the values received within the traceReference and 
traceReference2 parameters within ActivateTraceModeArg. 

- Trace-Depth-List AVP shall be present if a Trace-DepthList parameter was present within 
ActivateTraceModeArg . 

- Trace-NE-Type-List AVP shall be present if a TraceNE-TypeList parameter was present within 
ActivateTraceModeArg . 

- Trace-Depth-List AVP shall be present if a Trace-DepthList parameter was present within 
ActivateTraceModeArg . 

- Trace-Interface-List AVP shall be present if a TracelnterfaceList parameter was present within 
ActivateTraceModeArg . 

Trace-Event-List AVP shall be present if a TraceEventList parameter was present within 
ActivateTraceModeArg . 

- OMC-Id AVP shall be present if a OMC-Id parameter was present within ActivateTraceModeArg. 

- Trace- Collection-Entity AVP shall be present if a TraceCollectionEntity parameter was present within 
ActivateTraceModeArg . 

MDT- Configuration AVP shall be present if a MDT-Configuration parameter was present within 
ActivateTraceModeArg . 

GPRS-Subscription-Data AVP shall be present if a gprsSubscriptionData parameter was present within 
InsertSubscriberDataArg. 

LCS-Info AVP shall be present if a LCS Information parameter was present within InsertSubscriberDataArg. 

CSG-Subscription-Data AVPs shall be populated with information received within the csg- 
SubscriptionDataList parameter within InsertSubscriberDataArg. 

Roaming-Restricted-Due-To-Unsupported-Feature AVP shall be present and set to "Roaming-Restricted- 
Due-To-Unsupported-Feature (0)" if the parameter roamingRestrictedlnSgsnDueToUnsupportedFeature was 
present within InsertSubscriberDataArg. Otherwise shall be absent. 

Teleservice-List AVP shall be present if a Teleservice List parameter was present within 
InsertSubscriberDataArg. 

Call-Barring-Infor-List AVP shall be present if a Call Barring Information List parameter was present within 
InsertSubscriberDataArg. 

MDT-User- Consent AVP shall be present if a MDT User Consent parameter was present within 
InsertSubscriberDataArg. 

Subscribed- VSRVCC AVP shall be present if a Subscribed vSRVCC parameter was present in a received EPS- 
SubscriptionData parameter within InsertSubscriberDataArg. 

PS-and-SMS-Only-Service-Provision AVP shall be present if a psAndSMS-OnlyServicePro vision parameter 
was present within InsertSubscriberDataArg. 

SMS-In-SGSN- Alio wed AVP shall be present if an smsInSGSN Alio wed parameter was present within 
InsertSubscriberDataArg. 
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8.2.3 UpdateGprsLocationArg mapping to ULR 

When the IWF needs to construct an ULR command as a result of receiving an UpdateGprsLocation message without a 
pdn-gw-update parameter within eps-info and without an isr-Information parameter within eps-info not indicating 
updateMME or without a skipSubscriberDataUpdate parameter within add-info (see section 7.2.2 step 3), the IWF shall 
populate AVPs of ULR as described below: 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

User-Name AVP shall be populated with the value received within the imsi parameter of UpdateGprsLocationArg. 

Supported-Features AVP shall be populated with a value mapped from received parameter supportedFeatures within 
sgsn-Capability. 

Terminal-Information AVP shall be present if an add-info parameter was received within UpdateGprsLocationArg. If 
present the received value of the imeisv parameter shall be mapped onto IMEI and (if present) Software Version. 

RAT-Type AVP shall be populated with the value received within the usedRAT-Type parameter of 
UpdateGprsLocationArg 

ULR-Flags AVP: Flags shall be set as follows: 

Single-Registration-Indication shall be set to 1 if the ISR-Information parameter within the EPS -Info 
parameter within UpdateGprsLocationArg is present and indicates "cancelSGSN"; otherwise shall be set to 0. 

- S6a/S6d-Indicator shall be set to 1 if the servingNodeTypelndicator parameter was present in 
UpdateGprsLocationArg; otherwise shall be set to 0. 

- Skip Subscriber Data shall be set to 1 if a skipSubscriberData parameter was present in 
UpdateGprsLocationArg; otherwise shall be set to 0. 

- GPRS-Subscription-Data-Indicator shall be set to 1 if the "GPRS Subscription Data not needed Indicator" was 
absent from UpdateGprsLocationArg; otherwise shall be set to 0. 

- Node-Type-Indicator shall be set to 1 if the "Node-Type Indicator" was present in UpdateGprsLocationArg; 
otherwise shall be set to 0. 

- Initial- Attach-Indicator shall be set to 1 if the initialAttachlndicator parameter within the ISR-Information 
parameter within the EPS-Info parameter within UpdateGprsLocationArg is present; otherwise shall be set to 0. 



Visited-PLMN-Id AVP shall populated with a value derived from the sgsn-Number parameter received within 
UpdateGprsLocationArg. 

SGSN-Number AVP shall be populated with the value received within the SGSN Number parameter of 
UpdateGprsLocationArg. 

UE-SRVCC-Capability AVP shall be present if a ue-srvcc-Capability parameter was present in 
UpdateGprsLocationArg. If present the AVP shall be populated with the received ue-srvcc-Capability parameter. 

MME-Number-for-MT-SMS AVP shall be populated with the value received within the mmeNumberforMTSMS 
parameter of UpdateGprsLocationArg. 

SMS-Register-Request AVP shall be populated with the value received within the smsRegisterRequest parameter of 
UpdateGprsLocationArg. 

SMS-Only AVP shall be populated with the value received within the sms-Only parameter of UpdateGprsLocationArg. 

8.2.4 ULA mapping to InsertSubscriberDataArg/ 

ActivateTraceModeArg/UpdateGprsLocationRes/Error 

When the IWF needs to construct a MAP InsertSubscriberData messages and/or a MAP- ActivateTraceMode message 
and/or a MAP-UpdateGprsLocation Ack message, as a result of receiving an ULA command (see sections 7.2.2 steps 5 
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and 6), the IWF shall populate sub-parameters of InsertSubscriberDataArg, ActivateTraceModeArg and 
UpdateGprsLocationRes/Error as described below: 

InsertSubscriberDataArg : 

imsi in InsertSubscriberDataArg shall be absent. 

msisdn in InsertSubscriberDataArg shall be populated with the value received within the MSISDN AVP within 
the Subscription-Data AVP within ULA. 

category in InsertSubscriberDataArg shall be absent. 

subscriberStatus in InsertSubscriberDataArg shall be populated with the value received within the Subscriber- 
Status AVP within the Subscription-Data AVP within ULA. 

bearerServiceList in InsertSubscriberDataArg shall be absent. 

teleserviceList in InsertSubscriberDataArg shall be absent 

provisionedSS in InsertSubscriberDataArg shall be absent. 

odb-Data in InsertSubscriberDataArg shall be populated with the value received within the Operator- 
Determined-Barring AVP and HPLMN-ODB AVP AVP within the Subscription-Data AVP within ULA. 

roamingRestrictedDueToUnsupportedFeature in InsertSubscriberDataArg shall be absent. 

regionalSubscriptionData in InsertSubscriberDataArg shall be populated with the value received within the 
Regional-Subscription-Zone-Code AVPs within the Subscription-Data AVP within ULA. 

vbsSubscriptionData in InsertSubscriberDataArg shall be absent. 

vgcsSubscriptionData in InsertSubscriberDataArg shall be absent 

vlrCamelsubscriptionlnfo in InsertSubscriberDataArg shall be absent. 

naea-PreferredCI in InsertSubscriberDataArg shall be absent. 

gprsSubscriptionData in InsertSubscriberDataArg shall be populated with GPRS -Subscription Data received 
within the Subscription-Data AVP within ULA. 

roamingRestrictedlnSgsnDueToUnsupportedFeature in InsertSubscriberDataArg shall be present if a 
Roaming-Restricted-Due-To-Unsupported-Feature AVP Subscription-Data AVP within ULA. 

networkAccessMode in InsertSubscriberDataArg shall be populated with the value received within the 
Network- Access-Mode AVP within the Subscription-Data AVP within ULA. 

Isalnformation in InsertSubscriberDataArg shall be absent. 

Imu-Indicator in InsertSubscriberDataArg shall be absent 

Icslnformation in InsertSubscriberDataArg shall be absent. 

istAlertTimer in InsertSubscriberDataArg shall be absent. 

superChargerSupportedlnHLR in InsertSubscriberDataArg shall be absent. 

mc-SS-Info in InsertSubscriberDataArg shall be absent. 

cs-AUocationRetentionPriority in InsertSubscriberDataArg shall be absent. 

sgsn-CAMEL-Subscriptionlnfo in InsertSubscriberDataArg shall be absent. 

chargingCharacteristics in InsertSubscriberDataArg shall be populated with the value received within the 
3GPP-Charging-Characteristics AVP within the Subscription-Data AVP within ULA. 

accessRestrictionData in InsertSubscriberDataArg shall be populated with the value received within the 
Access-Restriction-Data AVP within the Subscription-Data AVP within ULA. 
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ics-Indicator in InsertSubscriberDataArg shall be absent. 

LCS Information in InsertSubscriberDataArg shall be populated with the value received within the LCS-Info 
AVP within the Subscription-Data AVP within ULA. 

Teleservice List in InsertSubscriberDataArg shall be populated with the value received within the Teleservice- 
List AVP within the Subscription-Data AVP within ULA. 

Call Barring Information List in InsertSubscriberDataArg shall be populated with the value received within 
the Call-Barring-Infor-List AVP within the Subscription-Data AVP within ULA. . 

psAndSMS-OnlyServiceProvision in InsertSubscriberDataArg shall be populated with the value received 
within the Subscription-Data AVP within ULA. 

smsInSGSNAUowed in InsertSubscriberDataArg shall be populated with the value received within the 
Subscription-Data AVP within ULA. 

Sub-parameters of eps-SubscriptionData in InsertSubscriberDataArg shall be populated as follows: 

apn-oi-Replacement shall be populated with the value received in the APN-OI-Replacement AVP within the 
Subscription-Data AVP within ULA. 

rfsp-id shall be populated with the value received within the RAT-Frequency-Selection-Priority-ID AVP within 
the Subscription-Data AVP within ULA. 

ambr shall be populated with the value received within the AMBR AVP within the Subscription-Data AVP 
within ULA. 

apn-ConfigurationProfile shall be populated with the value received within the APN-Configuration-Profile 
AVP within the Subscription-Data AVP within ULA. 

stn-sr shall be populated with the value received within the STN-SR AVP within the Subscription-Data AVP 
within ULA. 

csg-SubscriptionDataList shall be populated with values received within CSG-Subscription-Data AVPs within 
the Subscription-Data AVP within ULA. 

ue-ReachabilityRequestlndicator shall be absent. 

mdtUserConsent shall be populated with the value received within MDT-User-Consent AVP within the 
Subscription-Data AVP within ULA. 

subscribed-vsrvcc shall be present if the Subscribed-VSRVCC AVP is present within the Subscription-Data 
AVP within ULA. 

ActivateTraceModeArg: 

imsi in ActivateTraceModeArg shall be absent. 

TraceReference shall be populated with the value of Trace-ID part of the Trace-Reference AVP received within 
the Trace-Data AVP within the Subscription-Data AVP within ULA. 

TraceType shall be present with any value. 

TraceReference2 shall be populated with the value of MCC+MNC part of the Trace-Reference AVP received 
within the Trace-Data AVP within the Subscription-Data AVP within ULA. 

TraceDepthList shall be populated with the value received in the Trace-Depth-List AVP within the Trace-Data 
AVP within the Subscription-Data AVP within ULA. 

TraceNE-TypeList shall be populated with the value received in the Trace-NE-Type-List AVP within the 
Trace-Data AVP within the Subscription-Data AVP within ULA. 

TracelnterfaceList shall be populated with the value received in the Trace-Interface-List AVP within the Trace- 
Data AVP within the Subscription-Data AVP within ULA. 
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TraceEventList shall be populated with the value received in the Trace-Event-List AVP within the Trace-Data 
AVP within the Subscription-Data AVP within ULA. 

Omc-Id shall be populated with the value received in the OMC-Id AVP within the Trace-Data AVP within the 
Subscription-Data AVP within ULA 

TraceCoUectionEntity shall be populated with the address received within the Trace-Collection-Entity AVP 
within the Subscription-Data AVP within ULA. 

UpdateGprsLocationRes : 

hlr-Number in UpdateGprsLocationRes shall be populated with a value locally assigned to the IWF and 
consistent with SS7 routing principles. 

extensionContainer in UpdateGprsLocationRes shall be absent. 

add- Capability in UpdateGprsLocationRes shall be present. 

sgsn-mmeSeparationSupported in UpdateGprsLocationRes shall be present if the Separation Indication within 
the ULA-Flags AVP was set to 1 within ULA. 

MDT- Configuration shall be populated with the value received within the MDT-Configuration AVP within the 
Subscription-Data AVP within ULA. 

mmeRegisteredforSMS in UpdateGprsLocationRes shall be present if the "MME registered for SMS" flag 
within the ULA-Flags AVP was set to 1 within ULA. 

UpdateGprsLocation Error: 

An error of unknownSubscriber with unknownSubscriberParam containing a unknownSubscriberDiagnostic of 
"imsiUnknown" shall be sent if the received ULA command contains an Experimental-Result AVP with a value of 
"User Unknown". 

An error of unknownSubscriber with unknownSubscriberParam containing a unknownSubscriberDiagnostic of "gprs- 
epsSubscriptionUnknown" shall be sent if the received ULA command contains an Experimental-Result AVP with a 
value of "Unknown EPS Subscription". 

Other values within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate MAP error. 

8.3 Mapping of Parameters for the Cancel Location Procedure 
8.3.1 CancelLocationArg mapping to CLR 

When the IWF needs to construct a CLR command as a result of receiving a MAP-CancelLocation message (see 
sections 7.3.1 step 2, and 7.3.2 step 3), the the IWF shall populate AVPs of CLR as described below: 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

User-Name AVP shall be populated with the imsi value received within the identity parameter of CancelLocationArg. 

Supported-Features AVP shall be absent. 

CancellationType AVP shall contain the value MME_UPDATE_PROCEDURE if the parameter CancellationType 
within CancelLocationArg was set to updateProcedure and typeOfUpdate within CancelLocationArg was set to mme- 
change; the AVP shall contain the value SGSN_UPDATE_PROCEDURE if the parameter CancellationType within 
CancelLocationArg was set to updateProcedure and typeOfUpdate within CancelLocationArg was set to sgsn-change; 
the AVP shall contain the value SUBSCRIPTION_WITHDRAWAL if the parameter CancellationType within 
CancelLocationArg was set to subscriptionWithdraw; the AVP shall contain the value UPDATE_PROCEDURE_IWF 
if the parameter CancellationType within CancelLocationArg was set to updateProcedure and typeOfUpdate within 
CancelLocationArg was absent; the AVP shall contain the value INITIAL_ATTACH_PROCEDURE if the parameter 
CancellationType within CancelLocationArg was set to InitialAttachProcedure. 

CLR-Flags AVP: Flags shall be set as follows: 
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- S6a/S6d-Indicator shall be set to 1 if the TypeOfUpdate parameter was present in CancelLocationArg and indicates 
"mme-change"; it shall be set to if the TypeOfUpdate parameter was present in CancelLocationArg and indicates 
"sgsn-change". 

8.3.2 CLA mapping to CancelLocationRes/Error 

When the IWF needs to construct MAP-CancelLocation Ack message as a result of receiving an CLA command (see 
sections 7.3.1 step 4 and 7. 3.2. step 5), the IWF shall populate sub-parameters of CancelLocationRes/Error as described 
below: 

CancelLocationRes : 

extensionContainer in CancelLocationRes shall be absent. 

CancelLocation Error: 

Values other than SUCCESS within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate 
MAP error. 



8.3.3 CLR mapping to CancelLocationArg 



When the IWF needs to construct a MAP-CancelLocation message as a result of receiving an CLR command (see 
sections 7.3.2 step 2), the IWF shall open a MAP dialogue in application context version 3 and populate sub-parameters 
of CancelLocationArg as described below: 

identity in CancelLocationArg shall be populated with the imsi value of the User-Name AVP received within CLR. 

cancellationType in CancelLocationArg shall contain a value of updateProcedure if the Cancellation-Type AVP 
received in CLR contains the value MME_UPDATE_PROCEDURE or SGSN_UPDATE_PROCEDURE. The 
parameter shall contain a value of subscriptionWithdraw if the Cancellation-Type AVP received in CLR contains the 
value SUBSCRIPTION_WITHDRAWAL. The parameter shall contain a value of Initial AttachProcedure if the 
Cancellation-Type AVP received in CLR contains the value INITIAL_ATTACH_PROCEDURE. 

extensionContainer in CancelLocationArg shall be absent. 

typeOfUpdate in CancelLocationArg shall be set to sgsn-change if SGSN_UPDATE_PROCEDURE was received in 
the Cancellation-Type AVP within CLR, or INITIAL_ATTACH_PROCEDURE was received in the Cancellation-Type 
AVP within CLR and the S6a/S6d-Indicator flag was cleared in the CLR-Flags AVP within the received CLR. It shall 
be set to mme-change if MME_UPDATE_PROCEDURE was received in Cancellation-Type AVP within CLR, or if 
INITIAL_ATTACH_PROCEDURE was received in the Cancellation-Type AVP within CLR and the S6a/S6d- 
Indicator flag was set in the CLR-Flags AVP within the received CLR. Otherwise it shall be absent. 

8.3.4 CancelLocationRes / Error mapping to CLA 

When the IWF needs to construct an CLA command as a result of receiving a CancelLocation Ack/Error message (see 
sections 7.3.2 step 6), the IWF shall populate AVPs of CLA as described below: 

Result-Code / Experimental-Result AVP shall be set to: 

- DIAMETER_SUCCESS if a CancelLocationRes parameter was received in a TCAP ResultLast component; 

- an appropriate DIAMETER base protocol result code otherwise. 
Supported-Features AVP shall be absent. 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 



ETSI 



3GPP TS 29.305 version 1 1 .3.0 Release 1 1 52 ETSI TS 1 29 305 V1 1 .3.0 (201 2-1 0) 

8.4 Mapping of Parameters for the Purge Procedure 

8.4.1 PUR mapping to PurgeMS-Arg 

When the IWF needs to construct a MAP-PurgeMS message as a result of receiving an PUR command (see sections 
7.4.1 step 2 and 7.4.2. step 2), the IWF shall open a MAP dialogue in application context version 3 and populate sub- 
parameters of PurgeMS-Arg as described below: 

imsi in PurgeMS-Arg shall be populated with the imsi value of the User-Name AVP received within PUR. 

vlr-Number in PurgeMS-Arg shall be absent. 

sgsn-Number in PurgeMS-Arg shall be populated with a value locally assigned to the IWF and consistent with SS7 
routing principles. 

extensionContainer in PurgeMS-Arg shall be absent. 

8.4.2 PurgeMS-Res / Error mapping to PUA 

When the IWF needs to construct an PUA command as a result of receiving a PurgeMS Ack/Error message (see 
sections 7.4.1 step 4 and 7.4.2. step 6), the IWF shall populate AVPs of PUA as described below: 

Result-Code / Experimental-Result AVP shall be set to: 

- DIAMETER_SUCCESS if a PurgeMS-Res parameter was received in a TCAP ResultLast component; 

- DIAMETER_ERROR_USER_UNKNOWN if an error of unknownSubscriber without a diagnostic parameter or 
with a diagnostic parameter of imsiUnknown or gprs-eps-SubscriptionUnknown was received; 

- an appropriate DIAMETER base protocol result code otherwise. 
Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 
PUA-Flags AVP: Flags shall be set as follows: 

- Freeze M-TMSI shall be set to 1 if the freezeM-TMSI parameter was present within PurgeMS-Res; otherwise 
shall be set to 0. 

Freeze P-TMSI shall be set to 1 if the freezeP-TMSI parameter was present within PurgeMS-Res; otherwise 
shall be set to 0. 

8.4.3 PurgelVIS-Arg mapping to PUR 

When the IWF needs to construct a PUR command as a result of receiving a MAP-PurgeMS message (see section 7.4.2 
step 3), the the IWF shall populate AVPs of PUR as described below: 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

User-Name AVP shall be populated with the value received within the imsi parameter of PurgeMS-Arg. 

Supported-Features AVP shall be absent. 

8.4.4 PUA mapping to PurgeMS-Res/Error 

When the IWF needs to construct MAP-PurgeMS Ack message as a result of receiving a PUA command (see section 
7.4. 2. step 5), the IWF shall populate sub-parameters of PurgeMS-Res/Error as described below: 

PurgeMS-Res: 

freezeTMSI in PurgeMS-Res shall be absent. 

freezeP-TMSI in PurgeMS-Res shall be present if a Freeze-P-TMSI indication was received within the PUA- 
Flags AVP within PUA. 
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extensionContainer in PurgeMS-Res shall be absent. 

freezeM-TMSI in PurgeMS-Res shall be present if a Freeze-M-TMSI indication was received within the PUA- 
Flags AVP within PUA. 

PurgeMS Error: 

An error of unknownSubscriber with unknownSubscriberParam containing a unknownSubscriberDiagnostic of 
"imsiUnknown" shall be sent if the received AIA command contains an Experimental-Result AVP with a value of "User 
Unknown" . 

Values other than SUCCESS within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate 
MAP error. 

8.5 Mapping of Parameters for the Insert Subscriber Data 
Procedure 

8.5.1 InsertSubscriberDataArg mapping to IDR 

When the IWF needs to construct an IDR command as a result of receiving a MAP-InsertSubscriberData message (see 
sections 7.5.1 step 2, and 7.5.2 step 3), the IWF shall populate AVPs of IDR as described below: 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

User-Name AVP shall be populated with the value received within the imsi parameter of InsertSubscriberDataArg. 

Supported-Features AVP shall be absent. 

Subscription-Data AVP: See chapter 8.2.2. 

IDR-Flags AVP: Flags shall be set as follows: 

UE Reachability Request shall be set to 1 if the ue-reachabilityRequestlndicator was present within 
InsertSubscriberDataArg; othewise shall be set to or the AVP shall be absent. 

8.5.2 IDA mapping to InsertSubscriberDataRes/Error 

When the IWF needs to construct a MAP-InsertSubscriberData Ack message as a result of receiving an IDA command 
(see sections 7.5.1 step 4 and 7. 5. 2. step 5), the IWF shall populate sub-parameters of InsertSubscriberDataRes/Error as 
described below: 

InsertSubscriberDataRes : 

teleserviceList in InsertSubscriberDataRes shall include all teleserviceCodes that have been received within 
InsertSubscriberDataArg. 

bearerServiceList in InsertSubscriberDataRes shall include all bearerServiceCodes that have been received 
within InsertSubscriberDataArg. 

ss-List in InsertSubscriberDataRes shall include all ssCodes that have been received within 
InsertSubscriberDataArg. 

odb-GeneralData in InsertSubscriberDataRes shall include all odb categoties that have been requested within 
the received InsertSubscriberDataArg but are not supported by the serving node as indicated within the 
Supported-Feature AVP within IDA. 

regionalSubscriptionResponse in InsertSubscriberDataRes 

-shall be set to regionalSubscNotSupported if regional subscription was requested within the received 

InsertSubscriberDataArg but is not supported by the serving node as indicated within the Supported-Feature 

AVP within IDA. 

-shall be set to networkNode-AreaRestricted if regional subscription was requested within the received 

InsertSubscriberDataArg but a Network-Node-Area-Restricted indication has been received within the IDA- 
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Flags AVP within IDA. 
- otherwise shall be absent. 

supportedCamelPhases in InsertSubscriberDataRes shall be absent or shall indicate that no CAMEL phase is 
supported. 

extensionContainer in CancelLocationRes shall be absent. 

offeredCamel4CSIs in InsertSubscriberDataRes shall be absent. 

supportedFeatures in InsertSubscriberDataRes shall be populated with the information received within the 
Supported-Features AVP within IDA. 

InsertSubscriberData Error: 

Values other than SUCCESS within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate 
MAP error. 

8.5.3 IDR mapping to InsertSubscriberDataArg/ ActivateTraceModeArg 

When the IWF needs to construct a MAP-InsertSubscriberData message or a MAP-ActivateTraceMode message as a 
result of receiving an IDR command (see sections 7.5.2 step 2, and 7.10.2 step 2), the IWF shall open a MAP dialogue 
in application context version 3 and populate sub-parameters of InsertSubscriberDataArg/ ActivateTraceModeArg as 
described below: 

InsertSubscriberDataArg : 

imsi in InsertSubscriberDataArg shall be populated with the value received within the User-Name AVP within 
IDR. 

msisdn in InsertSubscriberDataArg shall be populated with the value received within the MSISDN AVP within 
the Subscription-Data AVP within IDR. 

category in InsertSubscriberDataArg shall be absent. 

subscriberStatus in InsertSubscriberDataArg shall be populated with the value received within the Subscriber- 
Status AVP within the Subscription-Data AVP within IDR. 

bearerServiceList in InsertSubscriberDataArg shall be absent. 

teleserviceList in InsertSubscriberDataArg shall be absent 

provisionedSS in InsertSubscriberDataArg shall be absent. 

odb-Data in InsertSubscriberDataArg shall be populated with the value received within the Operator- 
Determined-Barring AVP and HPLMN-ODB AVP AVP within the Subscription-Data AVP within IDR. 

roamingRestrictedDueToUnsupportedFeature in InsertSubscriberDataArg shall be absent. 

regionalSubscriptionData in InsertSubscriberDataArg shall be populated with the value received within the 
Regional-Subscription-Zone-Code AVPs within the Subscription-Data AVP within IDR. 

vbsSubscriptionData in InsertSubscriberDataArg shall be absent. 

vgcsSubscriptionData in InsertSubscriberDataArg shall be absent 

vlrCamelsubscriptionlnfo in InsertSubscriberDataArg shall be absent. 

naea-PreferredCI in InsertSubscriberDataArg shall be absent. 

gprsSubscriptionData in InsertSubscriberDataArg shall bepopulated with GPRS-Subscription Data received 
within the Subscription-Data AVP within IDR. 

roamingRestrictedlnSgsnDueToUnsupportedFeature in InsertSubscriberDataArg shall be present if a 
Roaming-Restricted-due-To-Unsupported-Feature AVP was received within the Subscription-Data AVP within 
IDR. 
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networkAccessMode in InsertSubscriberDataArg shall be populated with the value received within the 
Network- Access-Mode AVP within the Subscription-Data AVP within IDR. 

Isalnformation in InsertSubscriberDataArg shall be absent. 

Imu-Indicator in InsertSubscriberDataArg shall be absent 

Icslnformation in InsertSubscriberDataArg shall be absent. 

istAlertTimer in InsertSubscriberDataArg shall be absent. 

superChargerSupportedlnHLR in InsertSubscriberDataArg shall be absent. 

mc-SS-Info in InsertSubscriberDataArg shall be absent. 

cs-AUocationRetentionPriority in InsertSubscriberDataArg shall be absent. 

sgsn-CAMEL-Subscriptionlnfo in InsertSubscriberDataArg shall be absent. 

chargingCharacteristics in InsertSubscriberDataArg shall be populated with the value received within the 
3GPP-Charging-Characteristics AVP within the Subscription-Data AVP within IDR. 

accessRestrictionData in InsertSubscriberDataArg shall be populated with the value received within the 
Access-Restriction-Data AVP within the Subscription-Data AVP within IDR. 

ics-Indicator in InsertSubscriberDataArg shall be absent. 

LCS Information in InsertSubscriberDataArg shall be populated with the value received within the LCS-Info 
AVP within the Subscription-Data AVP within ULA. 

Teleservice List in InsertSubscriberDataArg shall be populated with the value received within the Teleservice- 
List AVP within the Subscription-Data AVP within ULA. 

Call Barring Information List in InsertSubscriberDataArg shall be populated with the value received within 
the Call- Barring-Infor-List AVP within the Subscription-Data AVP within ULA. 

Sub-parameters of eps-SubscriptionData in InsertSubscriberDataArg shall be populated as follows: 

apn-oi-Replacement shall be populated with the value received in the APN-OI-Replacement AVP within 
the Subscription-Data AVP within IDR. 

rfsp-id shall be populated with the value received within the RAT-Frequency-Selection-Priority-ID AVP 
within the Subscription-Data AVP within IDR. 

ambr shall be populated with the value received within the AMBR AVP within the Subscription-Data AVP 
within IDR. 

apn-ConfigurationProfile shall be populated with the value received within the APN-Configuration-Profile 
AVP within the Subscription-Data AVP within IDR. 

stn-sr shall be populated with the value received within the STN-SR AVP within the Subscription-Data 
AVP within IDR. 

subscribed-vsrvcc shall be present if the Subscribed-VSRVCC AVP is present within the Subscription-Data 
AVP within IDR. 

csg-SubscriptionDataList in InsertSubscriberDataArg shall be populated with information received within the 
CSG-Subscription-Data AVPs within the Subscription-Data AVP within IDR. 

ue-ReachabilityRequestlndicator in the InsertSubscriberDataArg shall be present if the corresponding 
information was present within the IDR-Flags AVP within an IDR; otherwise it shall be absent. 

psAndSMS-OnlyServiceProvision in InsertSubscriberDataArg shall be populated with the information received 
within the PS-and-SMS-Only-Service-Provision AVP within the Subscription-Data AVP within IDR. 

smsInSGSNAUowed in InsertSubscriberDataArg shall be populated with the information received within the 
SMS-In-SGSN- Allowed AVP within the Subscription-Data AVP within IDR. 
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Acti vateTraceMode Arg : 

imsi shall be populated with the value received within the User-Name AVP within IDR. 

TraceReference shall be populated with the value of Trace-ID part of the Trace-Reference AVP received within 
the Trace-Data AVP within the Subscription-Data AVP within IDR. 

TraceType shall be present with any value. 

TraceReference2 shall be populated with the value of MCC+MNC part of the Trace-Reference AVP received 
within the Trace-Data AVP within the Subscription-Data AVP within IDR. 

TraceDepthList shall be populated with the value received in the Trace-Depth-List AVP within the Trace-Data 
AVP within the Subscription-Data AVP within IDR. 

TraceNE-TypeList shall be populated with the value received in the Trace-NE-Type-List AVP within the 
Trace-Data AVP within the Subscription-Data AVP within IDR. 

TracelnterfaceList shall be populated with the value received in the Trace-Interface-List AVP within the Trace- 
Data AVP within the Subscription-Data AVP within IDR. 

TraceEventList shall be populated with the value received in the Trace-Event-List AVP within the Trace-Data 
AVP within the Subscription-Data AVP within IDR. 

Omc-Id shall be populated with the value received in the OMC-Id AVP within the Trace-Data AVP within the 
Subscription-Data AVP within IDR. 

TraceCoUectionEntity shall be populated with the address received within the Trace-Collection-Entity AVP 
within the Subscription-Data AVP within IDR. 

8.5.4 InsertSubscriberDataRes / Error mapping to IDA 

When the IWF needs to construct an IDA command as a result of receiving an InsertSubscriberData Ack/Error message 
(see sections 7.5.2 step 8), the IWF shall populate AVPs of IDA as described below: 

Result- Code / Experimental-Result AVP shall be set to: 

DIAMETER_SUCCESS if no InsertSubscriberData error component was received; 

- an appropriate DIAMETER base protocol result code otherwise. 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

IDA-Flags AVP: Flags shall be set as follows: 

- Network-Node-Area-Restricted shall be set to 1 if the regionalSubscriptionResponse parameter within 

InsertSubscriberDataRes indicated regionalSubscNotSupported; otherwise shall be set to 0. 

Supported-Features AVP: Support of features shall be indicated according to information received within the 
supportedFeatures parameter within InsertSubscriberDataRes. 

8.5.5 ProvideSubscriberlnfoArg mapping to IDR 

When the IWF needs to construct an IDR command as a result of receiving a MAP-ProvideSubscriberlnfo message (see 
sections 7.5.1 step 2, and 7.5.2 step 3), the IWF shall populate AVPs of IDR as described below: 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

User-Name AVP shall be populated with the value received within the imsi parameter of ProvideSubscriberlnfoArg. 

Supported-Features AVP shall be absent. 

Subscription-Data AVP shall be empty. 

IDR-Flags AVP: Flags shall be set as follows: 
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UE Reachability Request shall be set to 0. 

T-ADS Data Request shall be set to 1 if the t-adsData within the Requestedlnfo parameter within 
ProvideSubscriberlnfoArg was present; otherwise it shall be set to or the AVP shall be absent. 

EPS User State Request shall be set to 1 if the subscriberState within the Requestedlnfo parameter was present 
within ProvideSubscriberlnfoArg; otherwise it shall be set to or the AVP shall be absent. 

EPS Location Information Request shall be set to 1 if the locationlnformation within the Requestedlnfo 
parameter was present within ProvideSubscriberlnfoArg; otherwise it shall be set to or the AVP shall be 
absent. 

Current Location Request shall be set to 1 if the currentLocation within the Requestedlnfo parameter was 
present within ProvideSubscriberlnfoArg; otherwise it shall be set to 0. 

Local Time Zone Request shall be set to 1 if the localTimeZoneRequest within the Requestedlnfo parameter 
was present within ProvideSubscriberlnfoArg; otherwise it shall be set to 0. 

8.5.6 IDA mapping to ProvideSubscriberlnfoRes/Error 

When the IWF needs to construct a MAP-ProvideSubscriberlnfo Ack message as a result of receiving an IDA command 
(see sections 7.5.1 step 4 and 7. 5. 2. step 5), the IWF shall populate sub-parameters of ProvideSubscriberlnfoRes/Error as 
described below: 

Pro videSubscriberInf oRes : 

Sub-parameters of Subscriberlnfo in Pro videSubscriberInf oRes shall be populated as follows: 

imsVoiceOverPS-SessionsIndication shall be populated with the value received in the IMS-Voice-Over-PS- 
Sessions-Supported AVP within IDA. 

lastUE-ActivityTime shall be populated with the value received in the Last-UE-Activity-Time AVP within 
IDA. 

lastRAT-Type shall be populated with the value received in the RAT-Type AVP within IDA. 

eps-SubscriberState shall be populated with the value received in the EPS-User-State AVP within IDA. 

Sub-parameters of locationlnformationEPS shall be populated with the values of the corresponding AVPs 
received in the EPS -Location-Information AVP within IDA. 

timeZone shall be populated with the value received in the Time-Zone AVP within IDA. 

daylightSavingTime shall be populated with the value received in the Daylight-Saving-Time AVP within 
IDA. 

extensionContainer in ProvideSubscriberlnfoRes shall be absent. 

Pro videSubscriber Info Error: 

Values other than SUCCESS within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate 
MAP error. 

8.5.7 IDR mapping to ProvideSubscriberlnfoArg 

When the IWF needs to construct a MAP-ProvideSubscriberlnfo message as a result of receiving an IDR command (see 
sections 7.5.2 step 2), the IWF shall open a MAP dialogue in application context version 3 and populate sub-parameters 
of ProvideSubscriberlnfoArg as described below: 

ProvideSubscriberlnfoArg : 

imsi in ProvideSubscriberlnfoArg shall be populated with the value received within the User-Name AVP within 
IDR. 

Imsi in ProvideSubscriberlnfoArg shall be absent. 
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Sub-parameters of requestedlnfo in ProvideSubscriberlnfoArg shall be populated as follows: 

t-adsData in requestedlnfo shall be present if the "T-ADS Data Request" flag was set in the IDR-Flags AVP 
within IDR. 

subscriberState in requestedlnfo shall be present if the "EPS User State Request" flag was set in the IDR- 
Flags AVP within IDR. 

locationlnformation in requestedlnfo shall be present if the "EPS Location Information Request" flag was 
set in the IDR-Flags AVP within IDR. 

currentLocation in requestedlnfo shall be present if the "Current Location Request" flag was set in the IDR- 
Flags AVP within IDR. 

localTimeZoneRequest in requestedlnfo shall be present if the "Local Time Zone Request" flag was set in 
the IDR-Flags AVP within IDR. 

extensionContainer in ProvideSubscriberlnfoArg shall be absent. 

callPriority in ProvideSubscriberlnfoArg shall be absent. 

8.5.8 ProvideSubscriberlnfoRes/Error mapping to IDA 

When the IWF needs to construct an IDA command as a result of receiving an ProvideSubscriberlnfo Ack/Error 
message (see sections 7.5.2 step 8), the IWF shall populate AVPs of IDA as described below: 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

Supported-Features AVP shall be absent. 

Result- Code / Experimental-Result AVP shall be set to: 

- DIAMETER_SUCCESS if no ProvideSubscriberlnfo error component was received; 

- an appropriate DIAMETER base protocol result code otherwise. 

IMS-Voice-Over-PS-Sessions-Supported AVP shall be populated with the value received within the 
imsVoiceOverPS-SessionsIndication parameter within the Subscriberlnfo parameter of ProvideSubscriberlnfoRes. 

Last-UE-Activity-Time AVP shall be populated with the value received within the lastUE-ActivityTime parameter 
within the Subscriberlnfo parameter of ProvideSubscriberlnfoRes. 

RAT-Type AVP shall be populated with the value received within the lastRAT-Type parameter within the 
Subscriberlnfo parameter of ProvideSubscriberlnfoRes. 

EPS-User-State AVP shall be populated with the value received within the eps-SubscriberState parameter within the 
Subscriberlnfo parameter of ProvideSubscriberlnfoRes. 

AVPs within EPS-Location-Information AVP shall be populated with the values of the corresponding sub-parameters 
received within the locationlnformationEPS parameter within the Subscriberlnfo parameter of 
ProvideSubscriberlnfoRes. 

IDA-Flags AVP shall be absent. 

AVPs within Local-Time-Zone AVP shall be populated as follows: 

Time-Zone AVP shall be populated with the value received within the timeZone parameter within the 
Subscriberlnfo parameter of ProvideSubscriberlnfoRes. 

- Daylight-Saving-Time AVP shall be populated with the value received within the daylights avingXime 
parameter within the Subscriberlnfo parameter of ProvideSubscriberlnfoRes. 
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8.6 Mapping of Parameters for the Delete Subscriber Data 
Procedure 

8.6.1 DeleteSubscriberDataArg mapping to DSR 

When the IWF needs to construct a DSR command as a result of receiving a MAP-DeleteSubscriberData message (see 
sections 7.6.1 step 2, and 7.6.2 step 3), the the IWF shall populate AVPs of DSR as described below: 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

User-Name AVP shall be populated with the value received within the imsi parameter of DeleteSubscriberDataArg. 

Supported-Features AVP shall be absent. 

DSR-Flags AVP: Flags shall be set as follows: 

- RegionalSubscriptionWithdrawal shall be set to 1 if a regionalSubscriptionldentifier parameter was present in 
DeleteSubscriberDataArg; otherwise shall be set to 0. 

- Complete APN Configuration Profile Withdrawal shall be set to 1 if the allEPS-Data parameter was present 
within the EPS-SubscriptionDataWithdraw parameter within DeleteSubscriberDataArg; otherwise shall be set to 
0. 

- Subscribed Charging Characteristics Withdrawal shall be set to 1 if the chargingCharacteristicsWithdraw 
parameter was present within DeleteSubscriberDataArg; otherwise shall be set to 0. 

- PDN Subscription Context Withdrawal shall be set to 1 if the contextldList parameter was present within the 
EPS-SubscriptionDataWithdraw parameter within DeleteSubscriberDataArg; otherwise shall be set to 0. 

- STN-SR shall be set to 1 if the stn-srWithdraw parameter was present within DeleteSubscriberDataArg; 
otherwise shall be set to 0. 

- GMLC List Withdrawal shall be set to 1 if the GMLC List Withdraw parameter was present within 
DeleteSubscriberDataArg; otherwise shall be set to 0. 

- LCS Withdrawal shall be set to 1 if the SS code list parameter was present within DeleteSubscriberDataArg; 
otherwise shall be set to 0. 

- Complete PDP context list Withdrawal shall be shall be set to 1 if the allGPRS-Data parameter was present 
within the GPRS-SubscriptionDataWithdraw parameter within DeleteSubscriberDataArg; otherwise shall be set 
toO. 

- PDP context Withdrawal shall be set to 1 if the contextldList parameter was present within the GPRS- 
SubscriptionDataWithdraw parameter within DeleteSubscriberDataArg; otherwise shall be set to 0. 

- Roaming Restricted in due to unsupported feature shall be set to 1 if the 

roamingRestrictedlnSgsnDueToUnsupportedFeature parameter was present within DeleteSubscriberDataArg; 
otherwise shall be set to 0. 

- Trace Data Withdrawal shall be set to 0. 

- CSG Deleted shall be set to 1 if the csg-SubscriptionDeleted parameter was present within 
DeleteSubscriberDataArg; otherwise shall be set to 0. 

- APN-OI-Replacement shall be set to 1 if the apn-oi-replacementWithdraw parameter was present within 
DeleteSubscriberDataArg; otherwise shall be set to 0. 

- SMS Withdrawal shall be set to 1 if the SS-Code list parameter was present within DeleteSubscriberDataArg 
and the service codes are related to short message services; otherwise shall be set to 0. 

- Subscribed VSRVCC Withdrawal shall be set to 1 if the subscribed-vsrvcc Withdraw parameter was present 
within DeleteSubscriberDataArg; otherwise shall be set to 0. 
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Context-Identifier AVPs shall be populated with values received within the contextldList parameter within EPS- 
SubscriptionDataWithdraw or GPRS-SubscriptionDataWithdraw within DeleteSubscriberDataArg; 

8.6.2 DSA mapping to DeleteSubscriberDataRes/Error 

When the IWF needs to construct a MAP-DeleteSubscriberData Ack message as a result of receiving a DSA command 
(see sections 7.6.1 step 4 and 7. 6. 2. step 5), the IWF shall populate sub-parameters of DeleteSubscriberDataRes/Error as 
described below: 

DeleteSubscriberDataRes: 

regionalSubscriptionResponse in DeleteSubscriberDataRes shall be set to: 

- regionalSubscNotSupported if a corresponding information was received within the Supported-Feature AVP 
within DSA . 

networkNode-AreaRestricted if a Network-Node- Area-Restricted indication was received within the DS A- 
Flags AVP within DSA. 

extensionContainer in DeleteSubscriberDataRes shall be absent. 

DeleteSubscriberData Error: 

Values other than SUCCESS within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate 
MAP error. 

8.6.3 DSR mapping to DeleteSubscriberDataArg/ 
DeactivateTraceModeArg 

When the IWF needs to construct a MAP-DeleteSubscriberData message or a MAP-DeactivateTraceMode message as a 
result of receiving a DSR command (see sections 7.6.2 step 2, 7.11.2 step 2), the IWF shall open a MAP dialogue in 
application context version 3 and populate sub-parameters of DeleteSubscriberDataArg/DeactivateTraceModeArg as 
described below: 

DeleteSubscriberDataArg : 

imsi in DeleteSubscriberDataArg shall be populated with the value of the User-Name AVP received within 
DSR. 

basicServiceList in DeleteSubscriberDataArg shall be absent. 

ss-List in DeleteSubscriberDataArg shall be absent. 

roamingRestrictionDueToUnsupportedFeature in DeleteSubscriberDataArg shall be absent. 

regionalSubscriptionldentifier in DeleteSubscriberDataArg shall be present if a Regional-Subscription- 
Withdrawal indication has been received within the DSR-Flags AVP within DSR. If present, the value of the 
ZoneCode is arbitrary. 

vbsGroupIndication in DeleteSubscriberDataArg shall be absent. 

vgcsGroupIndication in DeleteSubscriberDataArg shall be absent. 

camelSubscriptionlnfo Withdraw in DeleteSubscriberDataArg shall be absent. 

extensionContainer in DeleteSubscriberDataArg shall be absent. 

gprsSubscriptionData Withdraw in DeleteSubscriberDataArg shall be present if corresponding information 
was received within the DSR-Flags AVP and GPRS -Context-Identifier AVPs within DSR. 

roamingRestrictedlnSgsnDueToUnsupportedFeature in DeleteSubscriberDataArg shall be present if a 
corresponding indication has been received within the DSR-Flags AVP within DSR. 

IsalnformationWithdraw in DeleteSubscriberDataArg shall be absent. 
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gmlc-List Withdraw in DeleteSubscriberDataArg shall be absent. 

istlnformationWithdraw in DeleteSubscriberDataArg shall be absent. 

specificCSI- Withdraw in DeleteSubscriberDataArg shall be absent. 

chargingCharacteristics Withdraw in DeleteSubscriberDataArg shall be present if a Subscribed-Charging- 
Characteristics-Withdrawl indication was received within the DSR-Flags AVP within DSR. 

stn-srWithdraw in DeleteSubscriberDataArg shall be present if a STN-SR indication was received within the 
DSR-Flags AVP within DSR. 

epsSubscriptionData Withdraw in DeleteSubscriberDataArg shall be present if a Complete- APN- 
Configuration-Profil-Withdrawal indication or a PDN-Subscription-Context-Withdrawl indication was received 
within the DSR-Flags AVP. The sub-parameter allEPS-Data shall be present if a Complete-APN-Configuration- 
Profile-Withdrawl indication was was received in the DSR-Flags AVP within DSR. The sub-parameter 
contextldList shall be present if a PDN-Subscription-Context-Withdrawl indication was received within the 
DSR-Flags AVP within DSR; if so, the contextldList shall be populatede with values received within the 
Context-Identifier AVPs within DSR. 

GMLC List Withdraw in DeleteSubscriberDataArg shall be present if a GMLC List Withdrawal indication was 
received within the DSR-Flags AVP. 

SS-Code List in DeleteSubscriberDataArg shall be present if corresponding information was received within the 
DSR-Flags AVP and SS-Code AVPs within DSR. 

apn-oi-replacement Withdraw in DeleteSubscriberDataArg shall be present if a APN-OLReplacement 
indication was received within the DSR-Flags AVP within DSR. 

csg-SubscriptionDeleted in DeleteSubscriberDataArg shall be present if a CSG Deleted indication was received 
within the DSR-Flags AVP within DSR. 

SS-Code List in DeleteSubscriberDataArg shall be present if SMS Withdrawal bit was set within the DSR-Flags 
AVP and SS-Code AVPs was within DSR. 

subscribed-vsrvcc Withdraw in DeleteSubscriberDataArg shall be present if a Subscribed VSRVCC 
Withdrawal indication was received within the DSR-Flags AVP within DSR. 

Deacti vateTraceMode Arg : 

imsi in DeactivateTraceModeArg shall be populated with the value received within the User-Name AVP within 
DSR. 

TraceReference in DeactivateTraceModeArg shall be populated with the value of Trace-ID part of the Trace- 
Reference AVP received within DSR. 

TraceReference2 in DeactivateTraceModeArg shall be populated with the value of MCC+MNC part of the Trace- 
Reference AVP received within DSR. 

8.6.4 DeleteSubscriberDataRes / Error mapping to DSA 

When the IWF needs to construct a DSA command as a result of receiving a DeleteSubscriberData Ack/Error message 
(see sections 7.6.2 step 6), the IWF shall populate AVPs of DSA as described below: 

Result- Code / Experimental-Result AVP shall be set to: 

- DIAMETER_SUCCESS if a DeleteSubscriberDataRes parameter was received in a TCAP ResultLast 
component; 

- an appropriate DIAMETER base protocol result code otherwise. 
Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 
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Supported-Features AVP shall be present and shall indicate support of Regional Subscription if a Regional- 
Subscription-Withdrawal indication was present within the DSR-Flags AVP within DSR and no 
regionalSubscNotSupported indication was received in regionalSubscriptionResponse in DeleteSubscriberDataRes. 

DSA-Flags AVP: Flags shall be set as follows: 

- Network-Node-Area-Restricted shall be set to 1 if a networkNode-AreaRestricted indication was received 
within the regionalSubscriptionResponse parameter within DeleteSubscriberDataRes; otherwise shall be set to 0. 

8.7 Mapping of Parameters for the Reset Procedure 

8.7.1 Reset (v1 or v2) mapping to RSR 

When the IWF needs to construct a RSR command as a result of receiving a MAP-Reset message with AC version 1 or 
version 2 (see sections 7.7.1 step 2, and 7.7.2 step 4), the the IWF shall populate AVPs of RSR as described below: 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

User-Id AVPs shall be populated with the values received within the HLR-Id parameters within hlr-list within 
Reset Arg. 

Supported-Features AVP shall be absent. 

8.7.2 RSR mapping to ResetArg (v1 or v2) 

When the IWF needs to construct MAP-Reset message as a result of receiving a RSR command (see section 7.7.2 step 
2), the IWF shall open a MAP dialogue in version 1 or version 2 according to an implementation option; note that the 
IWF shall be prepared to fall back to vl when v2 is chosen. Sub-parameters of ResetArg shall be populated as described 
below: 

networkResource in ResetArg (only vl) shall be set to hlr. 

hlr-Number in ResetArg shall be populated with a value locally assigned to the IWF and consistent with SS7 routing 
principles. 

hlr-List in ResetArg shall be populated with values received within User-Id AVPs within RSR. 

8.8 Mapping of Parameters for the Notification Procedure 
8.8.1 NOR mapping to UpdateGprsLocation-Arg 

When the IWF needs to construct a MAP-UpdateGprsLocation message as a result of receiving an NOR command (see 
sections 7.8.1 step 2 and 7.8.2. step 2), the IWF shall open a MAP dialogue in application context version 3 and 
populate sub-parameters of UpdateGprsLocation-Arg as described below: 

imsi in UpdateGprsLocationArg shall be populated with the value of the User-Name AVP received within NOR. 

sgsn-Number in UpdateGprsLocationArg shall be populated with a value locally assigned to the IWF and consistent 
with SS7 routing principles. 

sgsn- Address in UpdateGprsLocationArg shall be populated with the IP-address of the source node sending the NOR 
command. 

extensionContainer in UpdateGprsLocationArg shall be absent. 

sgsn- Capability in UpdateGprsLocationArg shall be absent. 

informPreviousNetworkEntity in UpdateGprsLocationArg shall be absent; 

ps-LCS-NotSupportedByUE in UpdateGprsLocationArg shall be absent 
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v-gmlc-Address in UpdateGprsLocationArg shall be absent. 

add-info in UpdateGprsLocationArg shall be present if a Terminal-Information AVP was present in the received NOR. 
If present the parameter shall be populated with the received IMEI and software version, and with a 
skipSubscriberDataUpdate indication. 

eps-info in UpdateGprsLocationArg shall be present and contain a pdn-gw-update parameter if the received NOR 
contained a MIP6-Agent-Info AVP. It shall be present and contain a isr-Information parameter if the received NOR 
contained a Single-Registration-Indication indication within the NOR-Flags AVP. 

servingNodeTypelndicator in UpdateGprsLocationArg shall be present. 

skipSubscriberData Update in UpdateGprsLocationArg shall be present. 

usedRAT-Type in UpdateGprsLocationArg shall be absent. 

gprsSubscriptionDataNotNeeded in UpdateGprsLocationArg shall be absent. 

nodeTypelndicator in UpdateGprsLocationArg shall be absent. 

areaRestricted in UpdateGprsLocationArg shall be present if the corresponding information was received within the 
NOR-Flags AVP within a NOR; otherwise it shall be absent. 

ue-reachablelndicator in UpdateGprsLocationArg shall be present if the corresponding information was received 
within the NOR-Flags AVP within a NOR; otherwise it shall be absent. 

ue-srvcc- Capability in UpdateGprsLocationArg shall be present if a UE-SRVCC-Capability AVP was present in the 
received NOR. If present the parameter shall be populated with the received ue-srvcc-Capability. 

8.8.2 UpdateGprsLocation-Arg mapping to NOR 

When the IWF needs to construct a NOR command as a result of receiving a MAP-UpdateGprsLocation message with a 
pdn-gw-update parameter within eps-info or with an isr-Information parameter within eps-info not indicating 
updateMME or with a skipSubscriberDataUpdate parameter within add-info or with ue-srvcc-Capability parameter but 
without usedRAT-Type parameter (see section 7.8.2 step 4), the the IWF shall populate AVPs of NOR as described 
below: 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

User-Name AVP shall be populated with the value received within the imsi parameter of UpdateGprsLocation-Arg. 

Supported-Features AVP shall be absent. 

Terminal-Information AVP shall be present if an add-info parameter was present inUpdateGprsLocationArg.. 

MIP6-Agent-Info AVP shall be present if pdn-gw-Identity was received within pdn-gw-update parameter within eps- 
info within UpdateGprsLocationArg. 

Service-Selection AVP shall be present if apn was received within pdn-gw-update parameter within eps-info within 
UpdateGprsLocationArg. 

NOR-Flags AVP: Flags shall be set as follows: 

- Single-Registration-Indication shall be set to 1 if a cancelSGSN indication was received within the ISR- 
Information within the eps-info within the UpdateGprsLocationArg; otherwise it shall be set to 0. 

- SGSN area restricted shall be set to 1 if an sgsnAreaRestricted indication was received within the 
UpdateGprsLocationArg; otherwise it shall be set to 0. 

- Ready for SM shall be set to 0. 

- UE Reachable shall be set to 1 if a ue-reachablelndicator was received within the UpdateGprsLocationArg; 
otherwise it shall be set to 0. 

Context-Identifier AVP shall be present if contextid was received within pdn-gw-update parameter within eps-info 
within UpdateGprsLocationArg. 
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UE-SRVCC-Capability AVP shall be present if a ue-srvcc-Capability parameter was present in 
UpdateGprsLocationArg. If present the AVP shall be populated with the received ue-srvcc-Capability parameter. 

8.8.3 NOR mapping to ReadyForSM-Arg 

When the IWF needs to construct a MAP-ReadyForSM message as a result of receiving an NOR command (see 
sections 7.8.1 step 2 and 7.8.2. step 2), the IWF shall open a MAP dialogue in application context version 3 and 
populate sub-parameters of ReadyForSMArg as described below: 

imsi in ReadyForSMArg shall be populated with the value of the User-Name AVP received within NOR. 

alertReason in ReadyForSMArg shall be populated with the value of the Alert-Reason AVP received within NOR. 

alertReasonlndicator in ReadyForSMArg shall be present. 

additionalAlertReasonlndicator in ReadyForSMArg shall be absent. 

extensionContainer in ReadyForSMArg shall be absent. 

8.8.4 ReadyForSM-Arg mapping to NOR 

When the IWF needs to construct a NOR command as a result of receiving a MAP-ReadyForSM message (see section 
7.8.2 step 4), the the IWF shall populate AVPs of NOR as described below: 

User-Name AVP shall be populated with the value received within the imsi parameter of ReadyForSMArg. 

Supported-Features AVP shall be absent. 

Terminal-Information AVP shall be absent. 

MIP6-Agent-Info AVP shall be absent. 

Context-Identifier AVP shall be absent. 

Service-Selection AVP shall be absent. 

Alert-Reason AVP shall be present and populated with the value received within the alertReason parameter of 
ReadyForSMArg. 

NOR-Flags AVP: Flags shall be set as follows: 

- Single-Registration-Indication shall be set to 0. 

- SGSN area restricted shall be set to 0. 

- Ready for SM shall be set to 1 . 

- UE Reachable shall be set to 0. 

8.9 Mapping of Parameters for the IMEI Check Procedure 



8.9.1 ECR mapping to ChecklMEI-Arg 



When the IWF needs to construct a MAP-ChecklMEI message as a result of receiving an ECR command (see section 
7.9.1 step 2), the IWF shall open a MAP dialogue in application context version 3 and populate sub-parameters of 
ChecklMEI-Arg as described below: 

imei in ChecklMEI-Arg shall be populated with the imei (and software version) as received within the Terminal- 
Information AVP within ECR. 

requestedEquipmentlnfo in ChecklMEI-Arg shall indicate equipments tatus. 

extensionContainer in ChecklMEI-Arg shall be absent. 
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8.9.2 ChecklMEI-Res / Error mapping to EGA 

When the IWF needs to construct an ECA command as a result of receiving a ChecklMEI Ack/Error message (see 
section 7.9.1 step 4), the IWF shall populate AVPs of ECA as described below: 

Result- Code / Experimental-Result AVP shall be set to: 

- DIAMETER_SUCCESS if a ChecklMEI-Res parameter was received in a TCAP ResultLast component; 

- DIAMETER_ERROR_UNKNOWN_EQUIPMENT if an error of unknownEquipment was received; 

- an appropriate DIAMETER base protocol result code otherwise. 

Auth-Session-State AVP shall be set to the value NO_STATE_MAINTAINED (1). 

Equipment-Status AVP shall be populated with a value as received within the equipmentStatus parameter within 
ChecklMEI-Res. 

8.1 Mapping of Parameters for the Trace Activate Procedure 

8.10.1 ActivateTraceMode-Arg mapping to IDR 

When the IWF needs to construct an IDR command as a result of receiving a MAP-ActivateTraceMode message (see 
sections 7.10.1 step 2), the IWF shall populate AVPs of the IDR as described below: 

User-Name AVP shall be populated with the value received within the imsi parameter of ActivateTraceModeArg. 

Supported-Features AVP shall be absent. 

Subscription-Data AVP shall be present and populated as follows: 

Trace-Data AVP shall be present and populated as in chapter 8.2.2. 

All other sub-AVPs shall be absent. 

8.1 0.2 IDA mapping to ActivateTraceMode-Res / Error 

When the IWF needs to construct a MAP-ActivateTraceMode Ack message as a result of receiving an IDA command 
(see sections 7.10.1 step 4), the IWF shall populate sub-parameters of ActivateTraceMode Res/Error as described 
below: 

Acti vateTraceModeRes : 

traceSupportlndicator shall be present if an indication of support of this feature was received within the 
Supported-Feature AVP within IDA; Otherwise, it shall be absent. 

extensionContainer shall be absent. 

ActivateTraceMode Error: 

Values other than SUCCESS within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate 
MAP error. 

8.1 1 Mapping of Parameters for the Trace Deactivate Procedure 
8.1 1 .1 DeactivateTracelVlode-Arg mapping to DSR 

When the IWF needs to construct an DSR command as a result of receiving a MAP-DeactivateTraceMode message (see 
sections 7.11.1 step 2), the IWF shall populate AVPs of DSR as described below: 
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User-Name AVP shall be populated with the value received within the imsi parameter of DeactivateTraceModeArg. 

Trace-Reference AVP shall be populated with the values received within the traceReference and traceReference2 
parameters of DeactivateTraceModeArg. 

Supported-Features AVP shall be absent. 

DSR-Flags AVP: Trace Data Withdrawal shall be set to 1. All other Flags shall be set as 0. 

Context-Identifier AVPs shall be absent. 

8. 11 .2 DSA mapping to DeactivateTraceMode-Res / Error 

When the IWF needs to construct a MAP-DeactivateTraceMode Ack message as a result of receiving an DSA 
command (see sections 7.11.1 step 4), the IWF shall populate sub-parameters of DeactivateTraceMode Res/Error as 
described below: 

Deacti vateTraceModeRes : 

extensionContainer shall be absent. 

DeactivateTraceMode Error: 

Values other than SUCCESS within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate 
MAP error. 
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Annex A: IWFs for the support of SMS capable MMEs 



A.1 



General 



This Annex describes the various cases of IWFs used for SMS related interfaces. 

A.2 IWF related to the SGd interface between MME and central 
SMS functions 

A.2.1 Introduction 

The clause A.2 with its subclauses describes the IWFs used between an MME, supporting the SGd interface and 
Central SMS functions (SMS-GMSC, SMS-IWMSC, SMS Router) supporting a MAP E interface. 

A.2. 2 General considerations 

Void 

A.2. 3 Interworking scenarios 
A.2.3.1 One IWF scenario 

This interworking scenario, illustrated in figure A.2. 3. 1-1, is between a MME supporting SGd interface based on 
Diameter and central SMS functions (SMS-GMSC, SMS-IWMSC, SMS Router) supporting a MAP based E interface 
for SMS with one IWF in the path. 

This IWF scenario can be an inter PLMN use case where the MME and the IWF are in the Visited PLMN. 

This IWF scenario can be an intra PLMN use case where the central SMS functions are supporting MAP based 
interfaces. 




EforSMS- 



SMS-GMSC 
SMS-IWMSC 
SMS Router 



Figure A.2.3.1 -1 SGd - E for SMS interworking scenario with one IWF 

For MO Forward short messages requests, the IWF shall use the SC address (E.164 number) received over SGd for 
routing over MAP. 

For MT Forward short messages, the IWF shall rely on the E.164 number of the MME used to route the MAP message 
towards the IWF to locally determine the Diameter address of the MME. 



A.2.3.2 



Two IWF scenario 



This interworking scenario, illustrated in figure A.2. 3. 2-1 is between a MME supporting a SGd interface based on 
Diameter and central SMS functions (SMS-GMSC, SMS-IWMSC, SMS Router) supporting a SGd interface based on 
Diameter with two IWF in the path, a MAP based E interface for SMS being used between the IWFs. 
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MME 




EforSMS- 



IWF2 



-SGd- 



SMS-GMSC 
SMS-IWMSC 
SMS Router 



Figure A.2.3.2-1 : Two IWFs scenario 

The IWFl is located in the PLMN of the MME. IWF2 is located in the PLMN of the SMS-GMSC or the SMS- 
IWMSC or the SMS Router. The SMS Router may be in a PLMN different from the PLMN of the SMS-GMSC. 

The IWFl needs not to be aware whether its connection via E for SMS interface is to an IWF or to central SMS 
functions (see One IWF scenario). 

For routing of MO and MT forward short messages, the IWFl shall behave as the IWF of the one IWF scenario 

For MO Forward short messages requests, the IWF2 shall rely on the El 64 number of the SMS-SC used to route the 
MAP message towards the IWF2 to locally determine the Diameter address of the SMS-IWMSC. 

For MT Forward short messages requests, the IWF2 shall use the El 64 number of the MME received over SGd to route 
the MAP message towards the IWFl. 



A.2.4 The mapping of procedures 
A.2.4.1 MO Forward Short Message 

A.2.4.1 .1 One IWF Scenario 

The mapping of the MO Forward Short Message procedure for this scenario is shown in figure A.2.4. 1.1-1: 




SGd 




MAPE 



-1.0FR- 



-4. OFA- 



SMS-IWMSC 



-2. MO-ForwardSM- 



-3. MO-ForwardSM Ack- 



Figure A.2.4.1 .1-1: Mapping of MO Forward Short Message procedure with one IWF 

1. The IWF receives a OFR message from the MME. 

2. The IWF opens a MAP v3 dialogue towards the SMS-IWMSC by sending MO-ForwardSM. 

3. The IWF receives MO-ForwardSM Ack from the SMS-IWMSC. 
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4. The IWF sends OFA to the MME. 

A.2.4.1 .2 Two IWFs Scenario 

The mapping of the MO Forward Short Message procedure for this scenario is shown in figure A.2.4.1. 2-1: 




SGd 



-1.0FR- 




MAPE 



-6. OFA- 




SGd 



-2. MO-ForwardSM- 



-5. MO-ForwardSM Ack- 



-3. OFR 



-4. OFA 



SMS-IWMSC 


^ 













Figure A.2.4.1. 2-1 : Mapping of MO Forward Short Message procedure with two IWFs 

1. The IWFl receives an OFR message from the MME. 

2. The IWFl opens a MAP v3 dialogue towards IWF2 by sending MO-ForwardSM. 

3. The IWF2 constructs the OFR message and sends it to the SMS-IWMSC. 

4. The IWF2 receives the OFA message from the SMS-IWMSC. 

5. The IWF2 closes the MAP dialogue with the IWF2 by sending MO-ForwardSM Ack. 

6. The IWFl sends the OFA message to the MME. 



A.2.4.2 



MT Forward Short Message 



A.2.4.2.1 One IWF Scenario 

The mapping of the MT Forward Short Message procedure for this scenario is shown in figure A.2.4.2. 1-1: 



ETSI 



3GPP TS 29.305 version 11.3.0 Release 11 



70 



ETSI TS 129 305 V1 1.3.0 (2012-10) 




SGd 




MAPE 



-2. TFR- 



-3. TFA- 



SMS-GMSC 
or SMS Router 



-1.MT-ForwardSM- 



-4. MT-ForwardSM Ack- 



Figure A.2.4.2.1-1 : Mapping of MT Forward Short Message procedure with one IWF 

1. The IWF receives a MT-ForwardSM MAP v3 message from the SMS-GMSC or from the SMS Router. 

2. The IWF sends TFR to the MME. 

3. The IWF receives TFA. 

4. The IWF closes the MAP dialogue with the SMS-GMSC or the SMS Router by sending MT-ForwardSM Ack. 

A.2.4.2.2 Two IWFs Scenario 

The mapping of the MT Forward Short Message procedure for this scenario is shown in figure A.2.4.2.2-1: 




SGd 




MAPE 



-3. TFR- 



-4. TFA- 



IWF2 



< 2. MT-ForwardSM- 



-5. MT-ForwardSM Ack — ► 



SGd 



SMS-GMSC 
or SMS Router 



-1.TFR- 



-6. TFA- 



Figure A.2.4.2.2-1 : Mapping of MT Forward Short Message procedure with two IWFs 

1. The IWF2 receives a TFR message from the SMS-GMSC or the SMS Router. 
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2. The IWF2 opens a MAP v3 dialogue towards IWFl by sending MT-ForwardSM. 

3. The IWFl constructs the TFR message and sends it to the MME. 

4. The IWFl receives the TFA message from the MME. 

5. The IWFl closes the MAP dialogue with the IWFl by sending MT-ForwardSM Ack. 

6. The IWF2 sends an OFA message to the SMS-GMSC or the SMS Router. 

A.2.5 The mapping of parameters 

A.2.5.1 Mapping of Parameters for the MO Forward Short Message procedure 

A.2.5. 1 .1 OFR mapping to MO-ForwardSIVI-Arg 

When the IWF needs to construct a MAP MO-ForwardSM message as a result of receiving an OFR command (see 
subclause A.2.4.1.1 step 2), the IWF shall open a MAP dialogue in application context version 3 and populate sub- 
parameters of MO-ForwardSM-Arg as described below: 

sm-RP-DA in MO-ForwardSM-Arg shall be present and populated with the value received within the User-Name AVP 
within OFR. 

sm-RP-OA in MO-ForwardSM-Arg shall be present and populated with the value received within the MSISDN AVP 
within the User-Identifier AVP within OFR. 

Editor" s note: to investigate the case of MSISDN-less users as the sm-RP-OA is a mandatory field in MAP 

sm-RP-UI in MO-ForwardSM-Arg shall be present and populated with the value received within the SM-RP-UI AVP 
within OFR 

extensionContainer in MO-ForwardSM-Arg shall be present . 

imsi in MO-ForwardSM-Arg shall be present and populated with the value received within the User-Name AVP in the 
User-Identifier AVP within OFR. 

A.2.5.1 .2 MO-ForwardSM-Res / Error mapping to OFA 

When the IWF needs to construct an OFA command as a result of receiving a MAP MO-ForwardSM Ack/Error 
message (see subclause A.2.4.1.1 step 4), the IWF shall populate AVPs of OFA as described below: 

Result- Code / Experimental-Result AVP shall be set to: 

- DIAMETER_SUCCESS if a MO-ForwardSM-Res parameter was received in the TCAP ResultLast component; 

- DIAMETER_ERROR_FACILITY_NOT_SUPPORTED if an error of facility Not Supported was received; 

- DIAMETER_ERROR_S YSTEM_FAILURE if an error of systemFailure was received; 

- DIAMETER_SM_DELIVERY_FAILURE if an error of sm-DeliveryFailure was received; 

- an appropriate DIAMETER base protocol result code otherwise. 

Editor" s Note: The list of Diameter errors may be reviewed according to the ones that will be retained in 3GP TS 
29.338. 

SM-Delivery- Failure-Cause AVP: shall be populated as follows: 

SM-Enumerated-Deli very-Failure- Cause AVP shall be present and populated with the value received within 
the SM-EnumeratedDeliveryFailureCause parameter, when present, within the sm-DeliveryFailureCause of the 
MO-ForwardSM message. 

SM -Diagnostic-Info AVP shall be populated with the value received within the diagnosticlnfo parameter, when 
present, within the sm-DeliveryFailureCause within the MO-ForwardSM message. 
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SM-RP-UI AVP shall be populated with the value received within the sm-RP-UI parameter, when present, of the MT- 
ForwardSM-Res message. 

A.2.5.1 .3 MO-ForwardSM-Arg mapping to OFR 

When the IWF needs to construct a OFR command as a result of receiving a MAP MO-ForwardSM message (see 
subclause A.2.4.1.2 step 3), the IWF shall populate AVPs of OFR as described below: 

User-Name AVP shall be present and populated with the value received within the sm-RP-DA parameter of MO- 
ForwardSM-Arg and translated into an UTF8 String format. 

User Identifier AVP shall be present and shall be populated as follows: 

User-Name AVP shall be present and populated with the value received within the imsi parameter of MO- 
ForwardSM-Arg and translated into an UTF8 String format. 

MSISDN AVP shall be populated with the value received within the sm-RP-OA parameter of MO-ForwardSM- 
Arg 

SM-RP-UI AVP shall be populated with the value received within the sm-RP-UI parameter of MO-ForwardSM-Arg 

Supported-Features AVP shall be absent. 

A.2.5.1 .4 OFA mapping to MO-ForwardSM-Res/Error 

When the IWF needs to construct MAP MO-ForwardSM Ack message as a result of receiving a OFA command (see 
subclause A.2.4.1.2 step 5), the IWF shall populate sub-parameters of MO-ForwardSM-Res/Error as described below: 

mo-ForwardSM-Res: 

sm-RP-UI in MO-ForwardSM-Res shall be populated with the value received within the SM-RP-UI AVP when 
present. 

extensionContainer in MT-ForwardSM-Res shall be absent. 

mo-ForwardSM Error: 

Values other than SUCCESS within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate 
MAP error. 

Editor" s note: further investigation to be done for error cases and in particular the mapping of the SM-Deli very- 
Failure-Cause AVP 

A.2.5.2 Mapping of Parameters for the MT Forward Short Message Procedure 

A.2.5.2.1 MT-ForwardSM-Arg mapping to TFR 

When the IWF needs to construct a TFR command as a result of receiving a MAP MT-ForwardSM message (see 
subclause A.2.4.2.1 step 2), the IWF shall populate AVPs of TFR as described below: 

User-Name AVP shall be populated with the value received within the sm-RP-DA parameter of MT-ForwardSM-Arg. 

SC-Address AVP shall be populated with the value received within the sm-RP-OA parameter of MT-ForwardSM-Arg 

SM-RP-UI AVP shall be populated with the value received within the sm-RP-UI parameter of MT-ForwardSM-Arg 

TFR-Flags AVP: Flags shall be set as follows: 

More-Messages- To-Send shall be set to 1 if the moreMessagesToSend parameter was present within MT- 
ForwardSM-Arg; otherwise shall be set to or the AVP shall be absent. 

Supported-Features AVP shall be absent. 



ETSI 



3GPP TS 29.305 version 1 1 .3.0 Release 1 1 73 ETSI TS 1 29 305 V1 1 .3.0 (201 2-1 0) 

A.2.5.2.2 TFA mapping to MT-ForwardSM-Res/Error 

When the IWF needs to construct MAP MT-ForwardSM Ack message as a result of receiving a TFA command (see 
subclause A.2.4.2.1 step 4), the IWF shall populate sub-parameters of MT-ForwardSM-Res/Error as described below: 

mt-ForwardSM-Res: 

sm-RP-UI in MO-ForwardSM-Res shall be populated with the value received within the SM-RP-UI AVP when 
present. 

extensionContainer in MT-ForwardSM-Res shall be absent. 

mt-ForwardSM Error: 

Values other than SUCCESS within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate 
MAP error. 

Editor" s note: further investigation to be done for error cases and in particular the mapping of the SM-Delivery- 
Failure-Cause AVP 

A.2.5.1 .1 TFR mapping to IVIT- Forwards IVI-Arg 

When the IWF needs to construct a MAP MT-ForwardSM message as a result of receiving an OFR command (see 
subclause A. 2. 4. 2. 2 step 2), the IWF shall open a MAP dialogue in application context version 3 and populate sub- 
parameters of MT-ForwardSM-Arg as described below: 

sm-RP-DA in MT-ForwardSM-Arg shall be present and populated with the value received within the User-Name AVP 
within TFR. 

sm-RP-OA in MT-ForwardSM-Arg shall be present and populated with the value received within the SC-Address AVP 
within TFR. 

sm-RP-UI in MT-ForwardSM-Arg shall be present and populated with value received within the SM-RP-UI AVP 
within TFR 

moreMessagesToSend shall be present if the More-Messages-To-Send flag is set to 1 within the TFR-Flags AVP 
within MT-ForwardSM-Arg. 

extensionContainer in MT-ForwardSM-Arg may be present if it contains. 

smDeliveryTime in MT-ForwardSM-Arg may be present and populated with the value within the SM- 
Delivery-Timer AVP when received within TFR. 

smDeliveryStartTime in MT-ForwardSM-Arg may be present and populated with the value within the SM- 
Delivery- Start-Time AVP when received within TFR. 

NOTE: The value of the MME-Number-For-MT-SMS AVP is not conveyed in the MAP MO-ForwardSM 
message but is used by IWF2 for routing the MAP MO-ForwardSM message towards IWFl. 

A.2.5.1 .2 IVIT-ForwardSIVI-Res / Error mapping to TFA 

When the IWF needs to construct an TFA command as a result of receiving a MAP MT-ForwardSM Ack/Error 
message (see subclause A.2.4.2.2 step 6), the IWF shall populate AVPs of TFA as described below: 

Result-Code / Experimental-Result AVP shall be set to: 

- DIAMETER_SUCCESS if a MT-ForwardSM-Res parameter was received in the TCAP ResultLast component; 

- DIAMETER_ERROR_USER_UNKNOWN if an error of unidentifiedSubscriber was received; 

- DIAMETER_ERROR_ ABSENT_USER if an error of absentSubscriberSM was received; 

- DIAMETER_ERROR_USER_BUS Y_FOR_MT_SMS if an error of subscriberBusyForMT-SMS was received; 

- DIAMETER. ERROR_ILLEGAL_USER if an error of illegalSubscriber was received; 
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- DIAMETER. ERROR_ILLEGAL_EQUIPMENT if an error of illegalEquipment was received 

- DIAMETER_ERROR_S YSTEM_FAILURE if an error of systemFailure was received 

- DIAMETER_SM_DELIVERY_FAILURE if an error of sm-DeliveryFailure was received; 

- an appropriate DIAMETER base protocol result code otherwise. 

SM-Delivery- Failure-Cause AVP: shall be populated as follows: 

SM-Enumerated-Deli very-Failure- Cause AVP shall be present and populated with the value received within 
the SM-EnumeratedDeliveryFailureCause parameter, when present, of the MT-ForwardSM-Res message. 

SM -Diagnostic-Info AVP shall be populated with the value received within the diagnosticlnfo parameter, when 
present, within the sm-DeliveryFailureCause within the MT-ForwardSM-Res message. 

SM-RP-UI AVP shall be populated with the value received within the sm-RP-UI parameter, when present, of the MT- 
ForwardSM-Res message. 
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